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ABSTR ACT 

A prototype flight simulator for the Fiber-Optically Guided Missile (FOG-M) 
is presented. This prototype demonstrates the practicability and feasibility of 
using low-cost graphics hardware to produce acceptable simulation of flight over 
terrain generated from Defense Mapping Agency (DMA) digital elevation data. 
The flight simulator displays a dynamic, three-dimensional, out-the-window view 
of the terrain in real-time while responding to operator control inputs. The total 
system cost (software and hardware) of the simulator is an order of magnitude 
less than most flight simulation systems in current use. 
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I. INTRODUCTION 



Flight simulation has been an important computer graphics application, 
embracing a range of systems from a $32.00 program for a personal computer 
[Ref. l] to special purpose machines costing millions of dollars [Ref. 2]. The 
capabilities of these systems are spread across a range nearly as wide as their 
costs, with great variances in speed (frames displayed per second), realism, 
flexibility, and area of flight. We present here a system that is relatively 
inexpensive, yet still fast enough to present a real-time three-dimensional view of 
digitized terrain. We built this system on a commercially available, high- 
performance graphics workstation, the Silicon Graphics, Incorporated IRIS-2400 
Turbo. The IRIS system was selected because of its local availability and its 
performance capabilities. The flight simulator presented here does not use the 
natural color and shape of individual terrain elements (in order to achieve real- 
time performance), but it is sufficiently realistic to provide the feeling of flight 
and allow identification of the displayed terrain and targets. 

FOG-M 

1. Background 

The project presented here was built in response to the United States 
Army Combat Developments Experimentation Center’s need to simulate the 
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operation of the Fiber-Optically Guided Missile (FOG-M) [Ref. 3], but this missile 
is also being considered for use by the United States Marine Corps [Ref. 4]. 
Simulation is necessary in order to test and evaluate the tactics, doctrine and 
training requirements associated with the missile without the expense and danger 
of actual firings during simulated combat field trials. The FOG-M is a generic 
family of remotely-piloted, video-guided munitions, but for the purpose of this 
prototype simulator, the weapons are all logically equivalent, and the entire 
family is referred to as “the missile.” In order to avoid security constraints, the 
parameters and operational characteristics used in this work were not taken from 
exact FOG-M specifications. The parameters and technical specifications are all 
estimates, based on reasonableness and consistency with general, unclassified 
descriptions of the FOG-M. 

2. Description 

The actual FOG-M missile is six inches in diameter, five and one-half feet 
high, weighs eighty-three pounds, and costs about $20,000 [Ref. 4]. It has a video 
camera mounted in its nose, which transmits a black-and-white picture back to 
the operator’s console (which consists of a television screen, a computer, and a 
joystick) over the fiber-optic link. (The simulator display offers the user the choice 
of either color or black-and-white; color is the default for the simulator despite the 
operator view of the missile being black-and-white. The color compensates for 
some of the loss in realism and identifiability inherent in a polygonal 
representation of natural objects). Before launch, in normal operation, the missile 
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is given a general direction to a target and the altitude of the highest point within 
its range. The simulator allows values in excess of FOG-M operational 
capabilities for speed, range, and altitude above ground level (AGL), but the 
default values of two hundred knots, ten kilometers, and one thousand meters are 
characteristic of this type of missile. As soon as the missile is in position, it begins 
transmitting video images. When launched, the missile rises to approximately 
two hundred feet above the highest terrain point, and then levels off in horizontal 
flight in the targeted direction. The operator controls the pan and tilt angle of 
the camera with the joystick, and can dial in changes to the heading and altitude 
of the missile. The operator also has the capability to zoom the camera’s field of 
view from eight degrees to fifty-five degrees, and to designate (“lock-on” to) a 
target for automatic homing by the missile. 

B. ASPECTS OF FLIGHT SIMULATION 

There are many aspects to flight simulation. Modern commercial simulators 
provide sophisticated mock-ups of cockpits and controls and highly detailed out 
the window views. By mounting the simulator on a moving platform, a true sense 
of the physical feelings of acceleration and roll can be achieved. These systems 
also COST, millions of dollars. 

One of the first decisions that must be made when designing a flight simulator 
is, “For what purpose will the simulator be used?” The answer to this question 
drives most of the design decisions that have to be made. Since the purpose of 
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this project is to provide a simulation of the FOG-M missile as viewed from its 
operator’s console, it is felt that the most important items to model are the 
simulated video display of the terrain and the actual operator controls. The 
terrain should appear realistic enough that its major features are recognizable to a 
person familiar with the area. The controls should allow for the same 
functionality as the actual console. The simulator must, of course, also provide a 
feeling that the missile is in motion over the terrain. The effectiveness of the 
feeling of motion provided by a flight simulator can be largely measured by two 
criteria; the realism of the displayed scene and the update rate of the display. 

1. Realism 

Many factors contribute to the perceived realism of a displayed natural 
scene. Early attempts to quantitatively measure realism consisted of counting the 
number of “edges” or lines that a scene contained. This later gave way to 
counting the number of “faces” or polygons in a scene. Since each polygon was 
colored in a single shade, it was felt that each polygon represented a single “bit” 
of information in the scene. Therefore, the more polygons the scene contained, 
the more “realistic” it was felt to be [Ref. 5:pp. 27-28]. 

The latest advances in computer graphics have also made this measure of 
effectiveness obsolete. With the introduction of systems that are able to till 
polygons with textured patterns, a single polygon can now contain thousands of 
“bits” of information. As a result, a scene drawn with a few textured polygons 
can appear more realistic than one with an order of magnitude more untextured 
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ones. Early textures consisted of superimposing things such as mathematical 
noise functions or stripes on the polygons. More recent advances have allowed the 
texture to be derived from digital photographs of a similar scene. For example, 
polygons representing a part of terrain covering by meadow could be filled with a 
digital texture derived from an aerial photograph of a meadow [Ref. 5: p. 28]. 

Since most currently available graphics workstations do not support the 
use of texture filled polygons, the use of texture Wcis deemed to be outside the 
scope of the current project. Rather, the project’s work concentrated on 
determining how realistically a scene could be rendered in real-time incorporating 
only the use of lighting and shading models along with terrain hidden-surface 
algorithms. These topics are covered in more detail in Chapter V. 

2. Frame Update Speed 

Another important aspect of a flight simulator’s performance is the speed 
at which it is capable of displaying successive frames in a scene. The faster the 
update rate, the more continuous the motion appears. As a reference, standard 
motion picture film is projected at a rate of twenty-four frames per second. 
Although the IRIS workstation is capable of displaying up to sixty frames per 
second, the amount of computation that must be done between successive frames 
in the simulation has limited the update rate to an average of three frames per 
second. While this presents a less than smooth motion, it is felt to be adequate 
for the purposes of the prototype. 



14 



C. ORGANIZATION 



The above sections of this chapter have provided background on flight 
simulation in general, and the missile whose flight is specifically being simulated. 
Chapter II provides an overview of the hardware used in running the simulation. 
The structure and content of the Defense Mapping Agency (DMA) Digital 
Terrain Elevation Data (DTED) are discussed in Chapter III. Chapter IV 
discusses the motivation behind and creation of the two-dimensional contour map 
displays. Chapter V covers the storage and use of the DMA DTED to produce a 
lighted and shaded three-dimensional polygonal terrain display. The mathematics 
and process involved in simulating flight over the terrain are detailed in Chapter 
VI. Chapter VII discusses the creation, insertion, animation, and designation of 
targets. Chapter VIII covers the creation and drawing of cultural features. 
Chapter IX contains a user’s guide for operation of the FOG-M simulator. 
Chapter X concludes with a discussion of limitations, future extensions and 
research topics, and summarizes the research conducted. Narrative descriptions of 
the modules and listings of the program source code for each of the modules are 
included as Appendices A and B respectively. 
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II. COMPUTER SYSTEM 



As discussed in Chapter I, flight simulators are nothing new. The significance 
of this work lies in the speed with which it was developed, the display rate 
achieved, and the realism and fidelity of the display in comparison to the cost of 
the system that supports it. This project was technically feasible only because of 
the capabilities and high performance of the IRIS (Integrated Raster Imaging 
System) Turbo 2400 Graphics Workstation, manufactured by Silicon Graphics, 
Incorporated. Others have also used the IRIS as a base on which to build flight 
simulators [Ref. 6]. This low-cost ($50,000 to $100,00) three-dimensional display 
system is summarized in Figure 2.1 and is discussed more fully below. 

A. HARDWARE AND SYSTEM OVERVIEW 

The IRIS has a conventional Von Neumann type computer architecture but 
adds custom-built special purpose VLSI circuits and a pipelined design to provide 
the graphics functions that are implemented in software on other comparably- 
priced workstations. Conceptually, there three pipelined components in the IRIS 
hardware: the applications/ graphics processor, the Geometry Pipeline, and the 

raster subsystem [Ref. 7:p. l-lj. The applications/graphics processor is a 
conventional Motorola MC68020 processor running at 16.7 MHz. This processor 
runs the applications program(s) within a UNIX System V operating system. 
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32 bit 16.7 MHz Motorola MC68020 CPU 
6 Megabytes of CPU Memory 

32 1024x768 bitplanes of Display Memory 

Hardware matrix multiplier & floating point accelerator 

Hardware Gouraud shading, depth cueing & backface polygon removal 

TM 

12 pipelined custom VLSI Geometry Engines 
16-bit Z-buffer for Hidden Surface Elimination 

2 72 Megabyte Winchester Disk Drives 

60 Hz non-interlaced 19" RGB high resolution monitor 
83 key up-down encoded keyboard 

3 button mouse 

32-button and 8-dial valuator boxes 
Unix System V 
Ethernet no VAX’s 
IRIS Graphics Library 



Features of 



the IRIS Turbo 2400 Graphics 
Figure 2.1 



Workstation 
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Applications either issue graphics commands in immediate mode, in which case 
they are sent through the Geometry Pipeline immediately as individual graphics 
primitives, or compile graphics commands into graphical objects, in which case 
they are sent through the Geometry Pipeline as a single geometric entity when 
explicitly called at some later point in time. 

The Geometry Pipeline takes commands in terms of the user’s world 
coordinates, performs specified matrix transformations on them using the matrix 
multiplier and floating point accelerator built into the hardware, and then clips 
and scales the transformed coordinates into screen coordinates. The raster 
subsystem takes the screen coordinates output by the Geometry Pipeline and 
updates the bitplanes (display memory) to contain the lines, polygons, or 
characters specified by the input coordinates. The raster subsystem also performs 
polygon fill, shading, depth-cueing, and hidden surface removal. A conventional 
video controller uses the values in the bitplanes and the color table to produce an 
image on the monitor. 

B. SOFTWARE 

The C programming language is native to UNIX and is the language used for 
all of '■he IRIS system software. The IRIS Graphics Library', which provides both 
high- and low-level graphics and utility commands, can be called in C, 
FORTRAN, Pascal, or LISP. However, due to the built-in bias of UNIX and the 
IRIS, plus the local pool of knowledge, the 0 programming language was the 
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pro forma choice for programming all parts of the FOG-M simulator. The IRIS 
User’s Guide [Ref. 7] breaks the Graphics Librarj' commands into the following 
twelve categories: 

- Global State commands initialize the hardware and control global variables, 
and are used mostly in FOG-M’s init iris routine. 

- Drawing Primitives are used throughout FOG-M. They create points, lines, 
polygons, circles, arcs, and text strings. 

- Coordinate Transformations specify mappings within and between user- 
defined world coordinates and screen coordinates. These are used to move 
targets and to simulate flight. 

- Drawing Attribute commands specify textures and fonts. Although texture 
would greatly improve the appearance of the terrain, the IRIS provided 
textures are applied in the screen coordinate system, so they do not scale or 
tilt to conform to the terrain, and produce a very artificial result. 

- Display Mode and Color commands determine how the bitplanes are used 
and what colors appear on the screen. These include the commands that set 
double-buffering, establish writemasks, and define the color table. 

- Input / Output commands initialize and read the dials and mouse. 

- Object Creation and Editing commands allow manipulation of complex 
displays as a single entity. They are used in all FOG-M displays. 

- Picking and Selecting commands are not used in FOG-M. 

- Geometry Pipeline Feedback commands are not used in FOG-M. 

- Curve and Surface commands draw complex curves and smooth surfaces. 
Experiments with these produced more realistic terrain images, but not even 
close to real-time, making flight animation impossible. 

- Shading and Depth— cueing commands provide Gouraud shading of polygons 
and intensities that vary with distance from the viewer. 

- Textport commands define an area of the screen for text. They are not used 
in FOG-M. 

Also available on the system, and used by FOG-M, are the math library with 
sine, cosine, arctangent, hypotenuse, and exponentiation functions, and routines 
that access the system clock in order to determine elapsed time. 
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III. DIGITAL ELEVATION TERRAIN DATA 



A. INTRODUCTION 

Unlike other flight simulation systems, which may rely on manual creation of 
the terrain [Ref. 8], the source data for the terrain in the FOG-M simulation is a 
Defense Mapping Agency (DMA) digital terrain elevation database (DTED) for 
Fort Hunter-Liggett. California. The database is not Level 1 DTED, but rather a 
DMA special product produced about 1980 at a higher resolution than normal 
Level 1 DTED [Ref. 9). Level 1 DMA data contains elevation points spaced at 
three arc-second intervals, or approximately every one hundred meters. The Fort 
Hunter-Liggett special data contains points at twelve and one-half meter spacing, 
which is eight times the resolution of Level 1 data. 

B. COVERAGE 

The area covered by the database is thirty-six kilometers wide and thirty-five 
kilometers high, with 6400 data points per square kilometer. This area includes 
most of Fort Hunter-Liggett plus some surrounding land, and is bounded by 
latitudes 36^^05' 00" (to the north) and 35° 50' 00"' (south) and longitudes 
121° 04' 30" (east) and 121° 20' 30" (west). In terms of Universal Transverse 
Mercator (UTM) coordinates, the area has easting (A) of 10SFQ41000 to 
10SFQ77000 and northing ( F) of 10SFQ60000 to 10SFQ95000. The database 
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appears to be based on DMA forty foot interval contour map products, because 
peaks tend to have flattened tops. This was confirmed both by a comparison of 
surveyed instrumentation sites on or near peaks with their digital terrain values 
[Ref. 10: pp. 1-2], and by a Bezier surface patch image of the data created locally. 

C. STRUCTURE 

The data is stored in an unformatted sequential file that is organized as a 
stream of integers. Each integer (sixteen bits) represents both the vegetation code 
and bald terrain elevation in feet at one sampling point, as illustrated in Figure 
3.1 below. 





Veg. Code 


Bald Terrain Elevation 


bit: 


15 14 13 


12 11 10 9876543210 



Figure 3.1 DTED Data Encoding 



The thirteen low-order (rightmost) bits contain the elevation, allowing a range 
from zero to 8191 feet, although the highest point in the database is 3744 feet. 
The three high-order (leftmost) bits specify one of eight vegetation codes, which 
are given in Table 3.1 below. Vegetation codes are only available for points 
within the boundaries of Fort Hunter-Liggett proper. The file is written one 
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TABLE 3.1 DTED VEGETATION CODES 



Code 


Description 


0 


Less than one meter 


1 


One to four meters 


2 


Four to eight meters 


3 


Eight to twelve meters 


4 


Twelve to twenty meters 


5 


Greater than twenty meters 


6 


No data available 


7 


Unused 



square kilometer at a time, beginning with the lower left one kilometer grid square 
(41,60), proceeding up the column to the upper left grid square (41,94), then 
doing the next column from bottom to top (42,60 to 42,94) and so on; the upper 
right one kilometer grid square (76,94) is the last one written. Within each one 
kilometer grid square, the individual data points are written in the same pattern, 
beginning with the lower left, doing each column from bottom to top, and doing 
the columns from left to right. This file layout is summarized in Figure 3.2. The 
position in the file of the elevation for a point expressed in five digit local UTM X 
and Y coordinates is found as shown in Equation 3.1. 



position = 35 * {integer {X/ 1000) — 41) + {integer {Y f 1000) — 59) (3.1) 



D. LOCATION 

The complete DTED file occupies 16,128,000 bytes of storage. Due to a local 
shortage of available disk space, this file must permanently reside on the UNIX 
VAX 11/785 system rather than on the IRIS system. The FOG-M simulator 
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presently operates on a ten kilometer square extract from this database. A 
program on the VAX called make— database— e allows interactive specification 
of the area and resolution desired, and produces an extract. This extract is sent 
over the Ethernet to the IRIS to serve as the input for a FOG-M run. However, if 
the data is sent directly, it is received with each pair of bytes swapped, so another 
program, swapdma, is run on the VAX before transmittal. This program swaps 
the low- and high-order bytes of each integer so that the swapping during 
transmission is cancelled. 
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IV. TWO-DIMENSIONAL TERRAIN MAP PORTRAYAL 



The two-dimensional representation of the terrain was begun as the first 
graphics portion of the system, in order to gain familiarity with the IRIS graphics 
workstation and the Defense Mapping Agency (DMA) digital terrain elevation 
data (DTED). Contour maps are the traditional approach to two-dimensional 
terrain portrayal, and thus were the basis for the two-dimensional images of the 
terrain generated here (Figure 4.1). Although these two-dimensional images are 
not true contour maps, they are still referred to as such in this study because of 
their close relation and common origin. The algorithms for determining and 
drawing the forty foot contour lines found on a normal contour map seemed non- 
trivial, so a simpler alternative was chosen. Each elevation datum is represented 
by a tile, with the implicit X and Z (easting and northing, respectively) 
coordinates of the elevation datum being the center of the tile. 

A. COLORS 

The color of a tile is determined by its vegetation code, and its intensity (or 
shading) by its elevation. The intent was to use green for tiles with vegetation 
and brown for tiles without vegetation. However, the DTED vegetation codes 
lump together both “no vegetation” and “vegetation less than one meter high.” 
Brown tiles thus include both unvegetated areas (e.g. rock slabs, areas above the 
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treeline) and grasslands or meadows. This is significant in the Fort Hunter- 
Liggett area, because most of the valleys are covered in grass, and all of the high 
ground is below the treeline. The result is a map with brown valleys and green 
ridgelines. While this was readily accepted as natural by most viewers, pilots 
with a background in low-level flight found it awkward, and contrary to their 
expectations (from flight charts) of green valleys and brown mountains. While 
this might be significant in other flight simulation applications (particularly those 
designed for pilots), the initial representation was deemed most appropriate for 
the target audience of the FOG-M simulator. 

A similar initial, intuitive choice was made for the elevation-keyed shading. 
High intensity (light) colors were used for higher elevations, and low intensity 
(dark) colors for lower elevations. This was accepted as natural by almost all 
viewers. The optimum number of intensities (shadings) to use in the map was 
experimentally determined to be sixteen. A small power of two was desirable due 
to the nature of the writemasks used to improve display speed. A large number of 
colors provides greater elevation definition and prevents large masses of the same 
color in areas where elevations change gradually. However, having too many 
colors destroys the contour-map effect, since adjacent colors are so close that no 
boundary is distinguishable between them. Eight shades each of green and brown 
were used initially. The shift to sixteen shades of each produces a better looking 
map. Due to the RGB (red, green, blue) nature of color creation on the IRIS, the 
greens were still barely differentiable at thirty-two shades, but the browns (a 
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combination of mostly red, some green, and, in some shades, a trace of blue) 
began to blend together. 

To determine the elevations at which color shades should change (in order to 
use the full range of shades), the majcimum and minimum elevations of the 
terrain section in use must be known. Rather than preprocess the data before each 
run, these values are coded as constants in a header file. The equation for which 
color index to use is straightforward (see Equation 4.1) but takes significant time 
when repeated ten thousand times. 

elevation— MIN 

index = base_index + * f of _shades (4.1) 

MAX-MIN 

Therefore, the fifteen points at which the shade changes are precalculated and 
stored in an array so that no calculations are needed at each point, just an array 
lookup. 

B. DRAWING 

The map can then be produced by determining the color and shade for each 
tile, and drawing it as a filled square. However, an increase in speed can be gained 
by exploiting the structure of the data and the line drawing hardware of the IRIS. 
The data is stiil processed a point at a time within each one kiiometer column, 
but no drawing is done until an elevation/shading breakpoint is reached. Then a 
single line of one tile’s width is drawn to color all tiles since the previous elevation 
breakpoint. 
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C. WRITEMASKS 



A more significant speed improvement (on the order of fifty per cent more 
frames per second) was achieved with writemasks. Writemasks are a relatively 
low-level hardware feature that can be used for many purposes. In the FOG-M 
simulator, they are used to prevent the contour map from being overwritten. 
This allows the map to be drawn only once into the bitplanes, and have it remain 
on the screen without being re-drawn during each frame update. In order to 
understand how writemasks work, one must understand the layout and use of the 
iris’s color table and bitplanes. 

1. Color Table 

The color table associates a particular binary number with a color. 
When the display system asks what color some number is, the color table replies 
with the intensities for the red, green and blue color guns that will produce the 
color defined for the input number. This input number is referred to as a 
colorindex. Thus the color displayed on the screen depends on the colorindex 
associated with a given pixel, and the color associated with that colorindex in the 
color table. Table 4.1 gives the color table entries that are the defaults on the 
IRIS workstation. 

2. Bitplanes 

The colorindex that is associated with each pixel is stored in the display 
memory, which is composed of bitplanes. Each bitplane has one bit for each pixel 
on the display screen, so a bitplane is 1024 bits wide, 768 bits high and one bit 
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TABLE 4.1 IRIS DEFAULT COLORINDEX DEFINITIONS 



Color 


Colorindex 


Decimal 


Binary ! 


Black 


0 


0000000000000000 ' 


Red 


1 


0000000000000001 


Green 


2 


0000000000000010 


Yellow 


3 


0000000000000011 


Blue 


4 


0000000000000100 


Magenta 


5 


0000000000000101 


Cyan 


6 


0000000000000110 


White 


7 


0000000000000111 



deep. When used in double — buf f er mode (as in FOG-M), the IRIS uses sixteen 

bitplanes (numbered 0 to 15) for each buffer. The frontbuffer is the one whose 
♦ 

binary contents define the image being displayed. While the frontbuffer is being 
displayed, the next image is created by issuing drawing commands which affect 
only the backbuf f er . Once a new image is completed in the backbuffer, the 
buffers are swapped, so the backbuffer becomes the frontbuffer and is displayed. 
The old frontbuffer becomes the backbuffer, and is then available for update. 

3. Writemask Example 

Consider the pixel at location (0,0) — the lower left corner of the screen. 
The colorindex of that pixel is determined by sixteen bits: one from the lower left 
corner of each bitplane. The display system reads those sixteen bits as a binary 
number (the colorindex), and uses the color table to determine what color to 
make that pixel. For example, using the default colors defined in Table 4.1 above, 
that pixel will be colored black if all sixteen bitplanes have zeroes in their lower- 
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left corners, since the value of the sixteen bit binary number OOOOOOOOOOOOOOOO 2 is 
zero. If the current color is set to magenta (color five, whose binary value has ones 
in bits zero and two) and a drawing command is issued, bitplanes zero and two 
are set to one, and all other bitplanes are set to zero, for every pixel covered by 
the drawing command. These pixels will now be displayed as magenta, because 
the colorindex constructed from the sixteen bitplanes will be 0000000000000101 2 
(5jq), and the color table tells the display system that color is magenta. 

The previous example showed that a drawing command works by 
placing ones in certain bitplanes, and zeroes in all of the rest, with the current 
color specifying which bitplanes get which. A writemask tells each bitplane to 
either allow or ignore the changes a drawing command says to make. In normal 
double-buffered usage, the writemask is IIIIIIIIIIIIIIII 2 , meaning all sixteen 
bitplanes should allow updates. Now suppose there is an image on the screen 
which uses just the default eight colors. Bitplanes three through fifteen are all 
zeroes, because all of the colors have colorindices with three or less binary digits, 
which will be in bitplanes zero, one, and two. If the writemask is changed to 
1111111 1111 IIOOO 2 after drawing the image, those lower three bitplanes are 
“frozen” and will not be changed by any drawing command. Setting the color to 
black and clearing the screen tvill not change anything. The upper bitplanes will 
be set to all zeroes, which they already were. The lower three bitplanes will be 
told to reset to zero, but will not do it because they are protected by the 
writemask. 
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Now suppose you want to draw a grey line on top of the image. The line 
only needs one color, so it can be drawn in one bitplane. (Two bitplanes will allow 
three more colors on top of the map, three bitplanes allow seven, etc.) The first 
“free” bitplane is number three. Turning on a bit in this plane (and not turning 
on any bits in higher planes) requires a colorindex in the range IOOO 2 to llllj (Sjo 
to ISjo)- Defining color eight in the color table as grey, making color eight the 
current color, and then drawing the line is sufficient to get the image into the 
bitplanes, but the display will not show the desired effect. If the image 
underneath the line is black (i.e. bitplanes zero through two are all zeroes form 
some pixels), the line will appear grey, as intended, for those pixels. However, if 
the image underneath the line is red (i.e. the lower bitplanes contain OOI 2 ), the 
composite colorindex retrieved by the display system is OOOOOOOOOOOOIOOI 2 or 9^^) 
and since color nine is not defined in the color table, it appears as black. Thus 
every colorindex that has bit three (because the line is in bitplane 3) set to one 
(i.e. colorindices IOOO 2 to IIII 2 , or 8 jq to must be defined as grey in order to 
produce the desired image. 

4. Writemasks in FOG-M 

The map image used in FOG-M is stored in the first six bitplanes 

(numbered 0 through 5) of both buffers, which means sixty-four colors are 

available: eight are the IRIS defaults, sixteen are shades of brown, sixteen are 

shades of green, and twenty-four are unused. The writemask defined as 

SAVEMAP (COjg or 000000001 IOOOOOO 2 ) allows things to be drawn on top of the 
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map in bitplanes six and seven. Colorindices 64 through 127 are all defined as 
blue in the color table, so anything drawn in bitplane six appears on top of the 
map in blue. Similarly, bitplane seven is used for red, with colorindices 128 
through 255 all correspondingly defined to be red. 

The speed improvement due to writemasks in FOG-M comes from not 
having to re-draw the map each time the screen is updated. The cost is the use of 
many more indices in the color table, which limits the number of colors available 
for use on top of the map. For our simulation system, with only two colors 
needed on top of the map, there is plenty of room in the color table. Therefore, 
the gain in speed comes at no real cost. 
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V. THREE-DIMENSIONAL TERRAIN CONSTRUCTION 



A. REPRESENTATION DECISIONS 
1. Polygons versus Patches 

Early experiments in the study involved attempting to display the 
terrain using parametric bi-cubic surface patches. A surface patch is simply a 
smooth curved surface fitted to a set of data points. A discussion of the theory 
and use of surface patches can be found in the IRIS User’s Guide [Ref. 7;sec. 11-3] 
and Hearn and Baker [Ref. ll:pp. 193-205]. It was quickly determined that it 
would not be possible to use surface patches to represent the terrain and still 
maintain a real-time update of the terrain during flight. 

An alternate method of displaying a three-dimensional object is through 
the use of a set of planar polygon surfaces that join at common edges to form the 
terrain object. This method has the advantage of being much simpler, and 
therefore faster, to generate and display. For this reason it was chosen for use in 
the project. 

Figure 5.i shows the method of constructing the terrain surface as a set 
of triangles. The term gridsquare is used in the remainder of the chapter to refer 
to a set of two triangles with a common hypotenuse that form a square of the 
terrain grid. 
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East 



North 

I 



View from above looking down on the terrain. 

-Terrain elevation points are connected 
to form triangular polygons with common 
edges . 



Figure 5,1 Polygonal Terrain Construction 
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2. Resolution 



The special DMA data file used in this project contains elevation data 
that is spaced at a twelve and one-half meter interval. One of the first questions 
which had to be answered concerning the three-dimensional portrayal of this data 
was, “In how fine a resolution can the data be displayed, while still allowing for a 
sufficient frame update speed?” Early test runs showed that using the full twelve 
and one-half meter resolution would be much too slow, although it provided an 
excellent representation of the terrain. An adequate frame update rate 
(approximately three to four frames per second) was achieved with a seventy-five 
meter resolution or every sixth data point. Since this was an early test, displaying 
terrain without any targets or cultural features, a one hundred meter resolution 
was decided upon for use in the remainder of the project. This allowed for an 
adequate “cushion” of processing time to complete the additional computations 
that would be needed in the final product, while still providing an adequate 
degree of resolution. 

3. Elevation Scaling 

After viewing the early representations of the terrain, it appeared that 
the hills did not give an appropriate appearance of height. Although this was a 
subjective judgement, it was shared by most people who viewed the display and 
compared it to aerial photographs of the area. Because of this, it wtis decided to 
scale the elevations of the displayed points upward. Two approaches, linear 
scaling and exponential scaling, were examined. 
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In the linear scaling approach, each elevation point was simply 



multiplied by a scale factor as shown in Equation 5.1. 



Elev -a * elev ,, 

new old 



(5.1) 



Using this approach, it appeared that a scaling factor between 1.5 and 2.0 was 
necessary to achieve the desired effect. 

In the exponential approach, the elevation of each point was raised to a 
fixed power as shown in Equation 5.2. 



Elev = Elev , , 

new old 



(5.2) 



This approach has the effect of exaggerating the higher elevations to a greater 
degree than the lower ones. It was chosen as the approach for use in the project 
based on subjective observations of the displays produced by the two methods. 
The scaling factor, <7, was chosen as 1.05. Using this factor produces the 
equivalent of a linear scaling of 1.5 for the maximum elevation and 1.4 for the 
minimum elevation contained in our area of interest. 

Subsequent to the decision to use an exaggerated elevation scale, 
research results were discovered which supported it. In a study conducted by the 
U.S. Army Research Institute for the Behavioral and Social Sciences, observers 
were asked to pick a computer generated line drawing that best matched actual 
terrain. The line drawings had different exaggerations of the vertical (elevation) 
scale. The overall ratios chosen by the four observers ranged from 1.25:1 to 
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1.50:1. The drawings presented to the observers had exaggeration ratios ranging 
from 1:1 to 1.75:1. [Ref. 12] 

4. Shading and Texturing 

As explained above, each one hundred meter square of the terrain, a 
“gridsquare,” is represented by two triangles in three-space that share a common 
diagonal edge. The process of applying colors to these polygons, shading, was the 
next area of research in the project. 

a. Elevation Based Shading 

Three different shading algorithms were investigated. The first was 
a simple algorithm where the shade of a polygon was a function of its elevation. 
Higher elevations are shaded in lighter shades of green while lower elevations 
receive darker shades. Equation 5.3 represents the assignment of a shade from the 
color map. 

dtv — Min Elev 

color index = base index -t- = * f of shades (5.3) 

Max Elev — Min Elev 

The darkest green is stored in the base index color map location and the lightest 
green in the baseindex + 4 of shades location. Although this approach works 
well for two-dimensional contour maps (see Chapter IV), and is currently used in 
another "low cost'’ simulator ^Ref. 6], it did not appear to present a realistic view 
of the terrain. An advantage of this approach, however, is that the calculation of 
the color index is simple enough to be done with no preprocessing. 
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b. Lambert’s Cosine Law Shading 

The second method of determining the shade for a polygon involved 
the use of a point light source and Lambert’s cosine law [Ref. ll:p. 278]. Let N 
be a unit normal vector to the polygon, and X be a unit vector in the direction of 

the light source. The angle between N and L, is the angle of incidence. 

Lambert’s Law states that the intensity of the light reflected from the polygon is 
proportional to cos $ (Equation 5.4). 

I a cos $ (5-4) 

In order to use this law, the normal vector {N), the light source vector (L), and 
the angle between them ($) must be known. N can be determined by taking the 
cross product of v\ and v2, where vl is a unit vector in the direction from vertex 

B to vertex C of the polygon, and v2 is a unit vector in the direction from vertex 

B to vertex A of the polygon (Equation 5.5 and Figure 5.2). 

N = vl X v2 (5.5) 

With N and L available, cos $ can be computed as their dot product (Equation 
5.7). 

cos ^ — N L (5-7) 

Since the intensity is proportional to cos the appropriate coior index to use can 
be computed as 

color index = min index + {jf^ shades*cos $) (5-8) 
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Figure 5.2 Lambert’s Cosine Law 
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where min index is the color index of the lowest intensity green and 
min index + f shades is the color index of the highest intensity green, 
c. Gouraud Shading 

The final shading model investigated involved the use of Gouraud 
shading. The purpose of Gouraud shading is to provide a continuous transition of 
shades across a polygon so that the shades at the edges of adjoining polygons 
match. This in effect eliminates the visible boundary between polygons and 
provides a smooth continuous surface. The Gouraud algorithm involves 

interpolating to determine the intensity to be used at each pixel along a scan line, 
and is illustrated in Figure 5.3 as reproduced from Hearn and Baker [Ref. ll:p. 
290]. To use the algorithm, intensity values for each vertex of the polygon must 
be known. In the project’s implementation, the intensity at each vertex was 
computed as the average of the intensity values for all the polygons meeting at 
that vertex, where the individual polygon’s intensity values were calculated using 
Lambert’s cosine law. 

The use of this model posed two problems. First, even though the 
IRIS supports Gouraud shading in its graphics library, its use increased the time 
between frames to an unacceptable rate (approximately one and one-half to three 
seconds between frames). Second, the smoothing of the algorithm worked too 
well, resulting in terrain displays that lacked the necessary position cues to detect 
motion. This second problem could be alleviated by adding artificial texture to 
the terrain but in light of the speed problem it was not pursued further. 



41 




For interpolated shading, the intensity value 
at point 4 is determined from intensity values 
at points 1 and 2, intensity at point 6 is 
determined from values at points 2 and 3, and 
intensifies at other points (such as 5) along 
the scan line are interpolated between the 
values at points 4 and 6. 

Figure 5.3 The Gouraud Shading Algorithm 
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d. Adding Texture 

Lambert’s cosine law was chosen as the shading model for use in the 
project, providing the most realistic display within the allowed computation time 
constraints. However, a problem with its use is that the flat valleys, with little 
variance in the surface normals of their polygons, produce large geographic areas 
having a near constant shade. This results in a lack of motion cues in these areas 
similar to that experienced with the Gouraud shading model. To remedy this 
situation, a simple artificial texture, in the form of a checker board, was imposed 
on the terrain. The checker board effect was implemented as follows. First, the 
shades for the two triangles in each gridsquare were averaged, and this average 
shade was used for both of them. This of course causes the visible boundary 
between the triangles to disappear leaving a square shaded in a single color. 
Second, two slightly offset color ramps were used with adjacent grid squares using 
different ramps to compute their shades. One ramp is composed of green 
intensities ranging from 255 to 50, while the other uses intensities ranging from 
245 to 40. * This causes the shades for two adjacent gridsquares with identical 
surface normals to vary, providing the necessary texturing. 



value of 255 is the highest intensity green obtainable, a value of zero indicates the absence 
of the color green. 
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B. INTERNAL DATA STRUCTURES 



Two global arrays are maintained which store the information necessciry to 
display the terrain. The first is a five-dimensional array, savetriangle, that stores 
the values of the coordinates for each triangle making up the terrain structure. 
The second is a two-dimensional array savecolor that stores the color map indices 
for each of the terrain’s grid squares. The purpose and range of each of 

savetriangle's indices is shown in Table 5.1. For example, 

sat;etnang/e[3][5][l][l][2] would contain the value of the Y coordinate (fifth 
dimension = 2), of the second vertex (fourth dimension = 1), of the northern 
triangle (third dimension = l), of the grid square with X index five and Z index 
three (second dimension = five and first dimension = three). 



TABLE 5.1 LAYOUT OF THE SAVETRIANGLE ARRAY 



Dimension 


Index Range 


Purpose 


Start 


End 


First 


0 


98 


Grid square index in the Z direction. 0 
is the southern most square, 98 is the 
northern most. 


Second 


0 


98 


Grid square index in the X direction. 0 
is the western most, 98 is the eastern 
most. 


Third 

j 


__ . 


1 

I 


Triangle identifier within a grid square. 

0 is the southern triangle. 1 is the 

northern. | 


Fourxh 


0 




Vertex number of the triangle. 0 is the 
first vertex, 2 is the last. 


Fifth 


0 


2 


Coordinate identifier of the vertex. 0 is 
the X coordinate, 1 the Y coordinate 
and 2 the Z coordinate. 
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Table 5.2 lists the purpose and ranges of each of savecolor's indices. For 
example, soueco/or [30] [10] contains the color map index to be used for the grid 
square with a Z index of thirty and an X index of ten. 



TABLE 5.2 LAYOUT OF THE SAVECOLOR ARRAY 



r ■ 

Dimension 
1 


Index Range 


Purpose 


Start 


End 


First 


0 


98 


Grid square index in the Z direction. 0 
is the southern most square, 98 is the , 
northern most. i 


Second 


0 


98 


Grid square index in the X direction. 0 j 
is the western most, 98 is the eastern 
most. 1 



These two arrays contain all the information necessary to construct an image 
of the terrain. The following chapter provides the details of using their data to 
create a real-time, updated image of the terrain as it is seen from the FOG-M’s 
camera. 
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VI. FLIGHT SIMULATION 



A. OVERVIEW 

The previous chapter discussed the methodology of constructing the three- 
dimensional terrain from the provided elevation data. This chapter’s purpose is 
to explain the details of displaying this terrain in real time as it is seen through 
the missile’s camera. 

The high level pseudocode for the main program’s terrain display loop is 
shown in Figure 6.1. Chapter VII explains the details of step two. The details of 
steps one and six are explained in Appendix B under the procedures readcontrols 
(for step one) and edit navbox and edit indbox (for step two). The remainder of 
this chapter discusses the details, considerations, and results of implementing 
steps three through five. 

B. UPDATING THE MISSILE’S POSITION 

Determining the missile’s new position can be broken into two cases: 

[1] the missile is under operator control and its new position is a function of the 
old position, the commanded direction of flight, the commanded altitude, 
and the commanded speed. 

[2] the missile is locked onto a target and its new position is a function of its old 
position, the position of the desired target, and the commanded speed. 

In both cases, a very large simplifying assumption is made to ignore the 

dynamics of the missile’s flight. This means that the missile is able to 
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While missile is flying do 

1) Read the values from the operator’s controls 

2) Determine new positions for all the targets 

3) Determine the new position for the missile 

4) Determine the position of where the camera is looking 

5) Display the terrain as seen by the camera 

6) Update the operator's control indicators 
End while 

Figure 6.1 Main Display Loop Pseudocode 



instantaneously change heading, speed, and altitude. This assumption was made 
only because of development time constraints. It is felt that the computations 
necessary to more realistically model the dynamics of the flight can be done 
without a serious degradation of the simulator’s performance. 

1. Cetse 1 - Operator Control 

Under this case the missile’s X,Y, and Z coordinates are computed as 
shown below. 

ADist = Speed* ATime (6-1) 



47 



Where 



- ADist is the distance traveled over the ground since the last position was 
calculated. 

- Speed is the missile's speed in feet per second and 

- A Time is the elapsed time since the last position was calculated 

Having calculated the distance the missile must move during this frame the 
missile’s new coordinates [MX ,MY ,MZ) can be calculated as 

+ ( 6 . 2 ) 

( 6 . 3 ) 

My,.. - ( 6 . 4 ) 

Where 

- is the commanded heading in radians 

- is the commanded altitude in feet 

- (7 is the altitude scaling factor (see Chapter V, Section A. 3). 

2. Case 2 - Locked Onto a Target 

In the case where the missile is locked onto a target, the missile’s new 
position is computed as follows. ADtst is computed as in Equation 6.1. Next the 
missile’s heading is computed so as to steer it directly toward the target’s 
position: 

Dir^^^ = nrct,an2{-[TZ-MZ\,[TX-MX]) (6.5) 
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Where 



- is the direction from the missile’s position to the target’s position 

- TX is the X coordinate of the target’s position 

- TZ is the Z coordinate of the target’s position 

- MX is the X coordinate of the missile’s position 

- MZ is the Z coordinate of the missile’s position 



- arctan2{a,b) is a function which returns the arctan 
0 to 2IT, based on the sign of a and b. 



a 

b . 



in the range 



Once 



is known, the missile’s new X and Z coordinates can be calculated as 






( 6 . 6 ) 

(6.7) 



Next the missile’s altitude {MY) is adjusted a proportion of the total altitude 
difference between it and the target, based on the ratio of ADist to the total 
distance (along the horizontal plane) to the target. 



Dist^^^ =V{ TX-MXf + {TZ-Mzf 



MY =MY 

new old 



ADist 

-TY)* 



( 6 . 8 ) 

(6,9) 



Where 

- is the distance to the target measured along a horizontal plane. 

- MY and TY are the Y (altitude) coordinates of the missile and target, 
respectively. 
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C. DETERMINING THE LINE OF SIGHT 



Once the new position of the missile has been calculated, the next step in 
displaying the terrain is to determine another point along the camera’s line of 
sight: the look-at position. This calculation is also broken into two cases based 
on whether the missile is or is not locked onto a target (see Figure 6.2). 

The case where the missile is locked on is trivial, the look-at position is 
simply set to the coordinates of the locked-on target. 



II 


(6.10) 


^1 

II 


(6.11) 


II 


(6.12) 



Where LX, L Y, and LZ are the X, Y, and Z coordinates of the look-at position. 
This centers the target in the displayed three-dimensional scene. 

When the missile is not locked onto a target, the camera’s look-at position is 
a function of the missile’s position, the missile’s heading, and the pan and tilt 
angles of the camera. It is determined as follows 



Dir look ~ Htad^^i-\- Pan 


(6.13) 


LX = MX^cos{Dir^^J*Dist^^J 


(6.14) 


LZ = MZ—\sin[Dir, Disi, 1 

1- \ lOO/C' lOO/CJ 


(6.15) 


LY = MF+[I?J5t,^^/tan(rz70] 


(6.16) 
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Figure 6.2 Determining the Camera’s Look-at Position 
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Where 



- is the direction the camera is looking 

- Pan is the pan angle of the camera 

- Tilt is the tilt angle of the camera 

- is an arbitrary distance over the ground that the camera looks ahead. 
Since the only purpose of LX, L Y, and LZ is to determine a point along the 
camera’s line of sight, any positive number will be acceptable. A value of five 
kilometers is currently used. 



D. DISPLAYING THE SCENE 

Once a line of sight has been determined, the next steps are to apply the 
appropriate viewing transformations, draw the filled polygons that make up the 
terrain, and add other items to the scene such as targets and roads. 

1. Viewing Transformations 

It is possible to project a three-dimensional object onto a two 
dimensional viewing surface in two basic ways. In one method, the parallel 
projection all the points of the object are projected along parallel lines. This has 
the advantage of preserving the relative dimensions and angles within an object 
and is used when accurate views of various sides of an object are needed such as 
in architectural drawings. In the other method, the perspective projection, all 
the points of an object are projected along lines that converge at a single point 
called the Center of Projection. In this method, relative dimensions are not 
preserved. Lines closer to the projection plane appear larger than those that are 
more distant. The perspective projection provides a view of three-dimensional 
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objects that is more realistic, similar to that provided by the human eye or a 
camera. Both these projections are illustrated in Figure 6.3. [Ref. ll:pp. 235-241] 
Because of its more realistic presentation of the scene, a perspective 
prpjection was used for the project’s three-dimensional scenes. The IRIS’s 
graphics library provides a procedure called perspective which constructs the 
necessary transformation matrix* to obtain a perspective projection. The matrix 
is defined as [Ref. 7:p. C-2] 



Perspective {f ovy , aspect , near ,f ar) = 
fovy 

cot{ ) 

2 



aspect 

0 

0 



0 



fovy 

cot{ ) 

2 



0 



0 



0 



0 



0 



far + near 
far — near 
2x farx near 
far— near 



-1 



0 



(6.17) 



Where 



- fovy is the field of view angle 

- aspect is the aspect ratio, a ratio of the distance a viewer sees in the X 
direction to the distance he sees in the Y direction. It is generally set to be 
the same as the ratio of the width to the height of the viewport. 

- near and far are the distances from the viewer to the near and far clipping 
planes. 

*A knowledge of using transformation matrices to perform graphical operations is assumed 
here. Hearn and Baker [Ref. llxhaps. 11-12] provides excellent coverage of the subject. 
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The perspective projection forms a view frustum as shown in Figure 6.4. 



Any object within the frustum between the near and far clipping planes will be 
displayed in the scene. Objects outside this view volume are clipped and 
discarded. 

Next, the frustum formed by the perspective projection must be 
positioned along the camera’s line of sight. This is accomplished by another 
transformation matrix constructed via a graphics library procedure named lookat. 
The lookat procedure takes the following inputs: 

- V^, and V^: the X, Y, and Z coordinates of the center of projection. 

- and F^: the X, Y, and Z coordinates of the look-at position. 

- Twist, a right handed rotation of the scene about the line of sight. 

The transformation matrix formed by lookat is actually the result of multiplying 
four other transformation matrices [Ref. 7:p. C-2] 



Lookat Twist) = 

Trans{— Y^,— Y^) x Pot^(G) x Pot^(^) x Rot^(— Twist) 



1 

0 



Where Trans{— Y^,— V^- V^) = 



0 0 0 
1 0 0 
0 1 0 



-V -V 1 

X y z 



(6.19) 
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Y 




dx 

dy 



The perspective command defines a near and 
far clipping plane, a field of view, and 
an aspect ratio. 



Figure 6.4 The Perspective Command 
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cos(0) 0 -S 2 ’n( 0 ) 0 



Bot^(e) = 



0 10 0 
5in(0) 0 cos(0) 0 
0 0 0 1 



( 6 . 20 ) 






1 0 0 0 | 
0 cos($) S 2 n($) 0 
0 — 5*n($) cos($) 0 
0 0 0 1 



( 6 . 21 ) 



Rot (—Twist) = 



cos{— Twist) sin{— Twist) 0 0 
— sin[— Twist) cos{— Twist) 0 0 
0 0 10 
0 0 0 1 



( 6 . 22 ) 



And 0 - sin 



P - V 

X X 



ViP.-K)+(Pr''yi 



(6.23) 



$ = sin ^ 



V -P 
y y 






(6.24) 



As can be seen, this transformation simply translates the center of projection to 
the origin, then rotates the view frustum about X and Y axes to align with the 
line of sight. Finally the twist angle is added with a rotation about the Z axis. 
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In the flight simulation, the twist angle is analogous to the “roll” angle of an 
aircraft or missile. A value of zero is currently used, but other values could be 
used if the roll of the missile during flight was added to the model. 

2. Determining Which Polygons to Draw 

After the correct viewing transformations have been applied, the 
polygons that comprise the scene must be drawn. Although the IRIS will “clip” 
polygons which lie outside the perspective projection’s view volume, an increase in 
frame update speed can be achieved by not attempting to draw those that 
obviously lie outside. This is discussed further in the following section on 
simulator performance. 

The term view — bound is used to describe a north-south oriented 
bounding box around those parts of the scene that are sent to the graphics 
pipeline. The view-bound is described by the index of the northernmost, 
southernmost, easternmost, and westernmost gridsquare to be drawn. It is 
calculated by extending (if necessary) the line-of-sight vector until it intersects the 
horizontal plane Y = Min elev, where Min elev is the minimum elevation value 
of the terrain. The view — bound is calculated as being 20 gridsquares to the 
north, south, east, and west of this intersection point. If the missile’s X and Z 
coordinates are not within the calculated view — hound, the bounds are extended to 
include them. Figure 6.5 illustrates this construction. 
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Hidden Surface Removal 



A final detail that must be taken care of is the removal of hidden 
surfaces from the scene. A hidden surface is simply a part of the scene that is 
obscured by some object in the foreground, such as a valley that it hidden behind 
a large hill. 

The IRIS supports a method in hardware called Z-Buffering. In this 
method, a buffer is maintained for each pixel position on the monitor and 
contains the “depth” (transformed Z coordinate) of the part of the scene that 
generated that pixel. Before drawing is started, the buffer is initialized to the 
maximum depth value (the value of the far clipping plane) for each pixel position. 
Before each new pixel is drawn, its depth is compared to the depth stored in the 
buffer. If its depth is greater than the stored depth it is not drawn. If it is less 
than the stored depth, it is drawn and its depth value replaces the value in the 
buffer. This method could not be used in the project for two reasons. First, with 
comparisons having to be made on a pixel-by-pixel basis, it slows down the frame 
update rate to an unacceptable level. Second, the IRIS does not allow the use of 
Z-buffering and double-buffering at the same time. Double-buffering is necessary 
to implement the animation of the scenes. 

Another common method of hidden surface removal is the painter 
algorithm. It derives its name from the way a painter would draw a scene on 
canvas, drawing in all the background and then adding foreground objects by 
painting over the background objects they obscure. Implementing this algorithm 
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in computer graphics means drawing the scene in an ordered fashion, such that 
the most distant objects from the viewer are drawn first and those closest to the 
viewer are drawn last. Since the gridsquares comprising the terrain form well 
defined rows and columns, an efficient implementation of this algorithm is 
possible. That implementation is described below. 

The implementation can be thought of on a conceptual level as follows. 
A line, perpendicular to the line-of-sight, is constructed to serve as a pseudo- 
scanline. Gridsquares within the view-bound are drawn as they are intersected by 
this scanline. The scanline is first positioned along the line-of-sight vector so that 
it intersects the far corner gridsquare of the view-bound. After all the gridsquares 
along the scanline have been drawn, it is moved one gridsquare closer to the view 
position, along the line-of-sight vector, and the process is repeated. This 
continues until all the gridsquares within the view-bound have been drawn. 
Figure 6.6 illustrates this process. 

From Figure 6.6, notice that each scanline passes through three 
gridsquares in a column, shifts over a column, then passes through three 
gridsquares in the next column. The number of gridsquares drawn in a column 
(or row) before advancing to the next column (or row) can be determined by 
computing the tangent of the acanline’s direction. If the magnitude of the 
tangent is greater than 1.0, scanlines will run and shift along columns of 
gridsquares. If it is less than 1.0, scanlines will run and shift along rows of 
gridsquares. The term .threshold is used in the remainder of the algorithm to 
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describe the number of gridsquares drawn before a shift of column (or row) takes 
place. It is computed as 



nearest integer\ta.xi[Dir , ) 



threshold = * 



nearest integer 



(tan(Z)ir )) 



-1 



if 



if 



ta.n{ Dir ) 

V scan' 






>1.0 



(6.25) 



<1.0 



The pseudocode for implementing the algorithm is shown in Figure 6.7. 
The case shown is for a line-of-sight direction that is in the first octant (between 

n 

0 and — radians). The algorithm for the other seven octants is similar, the 
4 

difference being the direction the scan line advances, and the direction it shifts 
when the threshold is reached. Table 6.1 summarizes these parameters for all 



eight octants. 

TABLE 6.1 VARYING PARAMETERS FOR THE SCANLINE ALGORITHM 
BASED ON THE OCTANT OF THE LOOK DIRECTION 



Octant 


Look Directions 


Scan Line Advances 


When Threshold is Reached 


From 


To 


From 


To 


i 1 

! 


0 


n/4 


North 


South 


Shift one column East 


2 


n/4 


n /2 


Eeist 


West 


Shift one row North 


3 


n /2 


3n/2 


West 


East 


Shift one row North 


4 


3H/2 


n 


North 


South 


Shift one column West 


5 


n 


sn/4 


South 


North 


Shift one column West 


6 

1 


511/4 


; .OH/ 2 ■ 


West 


East 


Shift one row South 


7 


311 2 


; “7Tf ,V ' 


East 


West 


Shift one row Souch 


8 


7II/4 


2n 


South 


North 


Shift one column East 



Notice the step draw gridsquare[z index][x index] in the algorithm. 
Since a gridsquare contains terrain, and can also contain roads and targets, an 
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Calculate the threshold value 



count ^ 0 

start X index ^ west view bound 
start z index ^ north_view_bound 

While st^a•t_z_index > south_view bound do 
z index start z index 

X index start x index 

while (x_index ^ east_view bound) and (z index ^ south_view_bound) do 

{ traverse a scanline } 

draw gridsqu 2 Lre[z_index][x_index] 

z index z_index - i (move it one gridsquare south} 
count ^ count -h 1 

if count = threshold then 

X index ^ x index 1 (move it one gridsquare east} 
count ^0 { reset count) 

endif 

end while 

{move on to next scanline: start it one gridsquare to the west) 
start X ^ start x - 1 
count ^ 0 

if (start_x < west_view_bound) then 
start_x ^ west view bound 
start z start z - threshold 
endif 

endwhile 



Figure 6.7 Pseudocode for the First Octant Scanline Algorithm 



ordering of these parts of the gridsquare must also take place. The two triangles 
forming the terrain are drawn first, next any roads are drawn, and finally any 
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targets are drawn. The details of integrating the targets and roads into the scene 
are covered in the following two chapters. 

The resulting scene is shown in Figure 6.8, a photograph of the IRIS 
monitor during the flight simulation. Note how the hidden surface removal allows 
the foreground hills to naturally obscure the valleys behind them. Also note the 
effect of the lighting model and texturing described in Chapter V. 

E. SIMULATOR PERFORMANCE 

Data collected while running the simulator shows that the average frame 
update rate is approximately four frames per second. The Unix profile utility 
was used to determine which procedures accounted for the majority of the 



simulator’s time usage. Table 6.2 shows the results for the top four routines. 
TABLE 6.2 FOG-M ROUTINES USING THE MOST CPU TIME 



CPU Time 


Routine Name 


Purpose 


16.9 


polf 


Iris graphics library filled polygon routine. 


13.7 


display terrain 


Output 3-D scene with hidden surface removal. 


8.7 


malloc 


C language built in routine for dynamic 
memory allocation. 


4.5 


gl findhash 


Low level Iris graphics library routine, used for 
the hash tables associated with graphical 
objects (Not user accessible). 



The top two entries in Table 6.2 are directly involved with outputting polygons to 
build the terrain image. It is therefore reasonable to believe that the frame 
update rate depends heavily on the number of polygons that are passed to the 
geometry engines. 
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Figure 6.9 is a scatterplot showing the frame update speed achieved when 
various numbers of polygons were attempted to be drawn. The data was 
generated by reading the system clock before each frame update and calculating 
the number of polygons based on the view — hound that was used during that 
frame. The graph clearly shows the effect the view-bound has on the frame 
update rate. The next two entries, malloc and gl findhash, are traceable to the 
making and deleting of the graphical objects that store the targets (this process is 
explained in Chapter VII). As an experiment, the construction and deletion of 
the targets’ objects was removed from the simulation and the targets were simply 
displayed in stationary positions. The profile results from the simulator run in 
this configuration is shown in Table 6.3. Figure 6.10 is another scatterplot, 
generated in the same manner as Figure 6.9, except that the simulator was run in 
the stationary target configuration. Eliminating the dynamic memory 
management associated with the target’s graphical objects increased the average 
frame update rate from 2.99 to 3.90 frames per second. Also, the maximum frame 
update rate achieved doubled from 7.5 to 15.0 frames per second. This would 
suggest that an area for further research is an improved algorithm for target 
updating that does not involve dynamically allocating memory. 

The fact that the frame update rate is so heavily dependent on the number of 
polygons passed to the geometry engine suggests that a more sophisticated 
method of determining the view-bound may pay off in increased performance. 
For example, the present method does not take into account the field of view 
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angle. It should be possible to bound the line-of-sight intersection point with less 
than twenty grid squares when the field of view angle is small. However, any new 
algorithm developed can not be so sophisticated that it negates the performance 
increase by requiring intensive computations. 



TABLE 6.3 FOG-M ROUTINES USING THE MOST CPU TIME 
(WITH STATIONARY TARGETS) 



% CPU Time 


Routine Name 


Purpose 


23.9 


polf 


Iris graphics library filled polygon routine. 


22.3 


display terrain 


Output 3-D scene with hidden surface removal. 


5.5 


color 


Iris graphics library routine which sets the 
current drawing color. 


4.1 


line intersect2 


Finds the intersection point of two lines. This 
routine is used exclusively during the road 
building process and therefore is not used at 
all in the display loop. 


4.0 


poly 


Iris graphics library unfilled polygon routine. 
Used during the display loop to outline the 
road segments. 
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VII. TARGET INTEGRATION 



A. GENERAL 

The primary targets of a FOG-M missile are tanks, helicopters, and 
reinforced ground installations. The simulator is designed to handle many types 
of targets, including various tanks and helicopters, but only a single type of tank 
is currently implemented. The prototype simulator provides an Ethernet 
networking capability to allow the input of actual target positions in real-time. 
This simulates the input that would be received by a production simulator during 
computerized mock combat field experiments. In its networking mode, the 
simulator receives target position and orientation data from an interactive 
program running on a different IRIS workstation. The target program, still in 
testing and not detailed in this study, provides the capability to dynamically 
insert and delete targets at any location, and to modify their speed and direction. 
In the simulator’s stand-alone mode, there are ten tanks defined by default that 
criss-cross the ten kilometer square terrain area. These tank targets move at a 
constant speed of fifteen knots and reverse direction when they reach one of the 
edges of the ten kilometer terrain square. No automated path planning is 
presently performed in either mode, so the tanks blithely traverse even the 
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steepest terrain. The default targets minimize this problem by traveling the length 
of the valleys for the most part. 

B. TARGET CREATION 

Target creation is simplified through the use of graphical objects. The actual 
image of a tank is defined initially by the tedious specification of the three 
coordinates of each vertex of each of the polygons that comprise the tank (Figure 
7.1). Using objects, this need only be done once, placed in an object, and then 
referred to by a single name within each target object. Thus each target is 
described by an object (the tank object) within another object (the target object). 
In addition to the tank object, the target object also contains the transformation 
commands that move the tank from the origin to its location on the terrain (a 
translation)., and face it in the direction it is moving (a rotation). 

1. The System Matrix 

The rotation and translation commands work by modifying the system 
matrix. The system matrix is a global data structure that is used to transform 
coordinates from the three-dimensional world space into the two-dimensional 
screen space. Each transformation can be performed as a series of computations 
on individual X. Y. and Z coordinates, but the transformations can also be 
accomplished with a single matrix multiplication. The IRIS has a matrix 
multiplier built into its hardware, so matrix operations are very efficient. At least 
three transformations must be applied to every endpoint on the tank: a coordinate 
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scaling, a translation, and a rotation. Rather than do three separate matrix 
multiplications, the three transformation matrices can be combined, so that all of 
the transformations are accomplished in a single matrix multiplication. The 
matrices are combined by applying each of them to the system matrix. Each 
point is now completely transformed through a single multiplication with the 
system matrix. When a new transformation is needed, the system matrix must be 
reset by applying the inverses of the old transformations, or by copying the 
original contents back into the system matrix. Two commands are provided with 
the IRIS to support the latter method. Pushmatrix takes a copy of the system 
matrix’s current contents and saves it on the system stack. After the 
transformations have been applied, and the drawing that used those 
transformations has been completed, the system matrix is reset by calling 
popmatrix., which retrieves the copy placed on the stack by pushmatrix and 
restores the contents of the system matrix to the previously saved values. 

2. Target Transformations 

The tank is initially defined with its center interior at the origin 
(coordinates (0,0,0)). While it is not important which point on or in the tank is 
placed at the origin, it is crucial that the tank be defined somewhere around the 
origin in order for the rotation command to have the desired effect. The original 
direction of the tank is significant only to the extent that it must be known in 
order to calculate the appropriate rotation to achieve a specified heading. The 
tank in FOG-M faces to the right (zero radians mathematically, or a compass 
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heading of ninety degrees) initially. During target creation, dummy (zero valued) 
rotation and translation commands are placed in the target object, to be updated 
for display by a later editing of the object. Since all rotation and translation 
commands affect the system matrix (as previously described) and are cumulative, 
each target object must apply its transformations, be drawn, and then remove 
those transformations so that latter drawing commands are not distorted. Within 
each target object, the contents of the system matrix are saved with a pushmatrix 
call, the appropriate rotation and translation commands are applied to the system 
matrix (in reverse order, due to the nature of matrix multiplication), the target is 
drawn by calling the tank object, and then popmatrix is called to reset the system 
matrix. 

C. ANIMATION 

Animation of the targets is accomplished using the objects and 
transformations described above. The targets must be moved slightly before 
being redrawn in the next frame. This requires new (A, Y,Z) coordinates, from the 
network or from local calculations. Then a global data structure is updated to 
indicate when in the display algorithm the target should be drawn, and the 
translation command in the target object is edited to provide the new coordinates. 
As each frame is displayed, targets appear in slightly shifted positions, and give 
the appearance of animated motion. 
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The calculation of new coordinates requires the maintenance of position, 
speed, and direction data for each target. The total distance traveled between 
screen updates is the product of the elapsed time (obtained from the IRIS’s real- 
time clock) and the target’s speed, scaled so the units match. In the networking 
version of the simulator this is done remotely; in the stand-alone version 
everything must be maintained locally. The target’s direction of travel is stored 
in radians, and is measured using the standard mathematical convention as 
opposed to a compass heading (Figure 7.2). This allows calculation of the the 
appropriate east/west (AX) and north/south (AZ) movement as follows: 

:1X = cos{direction) * time * speed * scale factor (”•!) 

AZ = —s\n{directton) * time * speed * scale factor (^-2) 

The new target (X,Z) position is the sum of the old position and the offsets 
(AX,AZ) from Equations 7.1 and 7.2. Since all of the current targets are tanks, 
their Y coordinates (altitude) should be taken from the height of the terrain 
underneath the tank. This is obtained from the DTED interpolation routine 
gnd level, which is called with the new [X,Z) coordinates as input parameters. 

D. DISPLAY 

Chapter Five explained the exploitation of the structure of the data and the 
use of the painter’s algorithm to solve the polygon ordering problem without 
resorting to slower or more complicated schemes like Z-buffering or Binary Space 
Partitioning [Ref. 13]. Targets cannot merely be drawn after the terrain because 
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Figure 7.2 Direction Conventions 
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of the same ordering problem. Otherwise, targets appear in front of everything, 
and it is impossible to simulate a target moving out of sight into the distance or 
behind some terrain feature. The implementation of the target display algorithm 
is greatly facilitated by the use of objects. Objects allow the grouping of drawing 
commands into a subroutine-like package, which can be edited (effectively 
allowing parameterization) and then displayed with a single command. A two- 
dimensional array of object “names” (the object — name — array) is initialized so 
each element of the array represents the target object to be drawn in the one 
hundred meter square of terrain with the same indices. Since the C programming 
language recognizes the value integer zero as FALSE, and anything else as TRUE, 
this array does double duty as an array of booleans indicating the presence or 
absence of a target object in a particular one hundred meter grid square. (No 
target objects are given the “name” zero, which would indicate FALSE.) A list of 
targets is used to reset this array to all zeroes before each screen update (i.e. only 
those elements that contained targets need to be zeroed) so maintenance overhead 
of the array is minimized. The new target positions are received over the 
network, or are calculated, based on each target’s position, speed, and direction, 
plus the elapsed real-time since the last update. The appropriate object-name- 
array indices are calculated from the new target po.sition and the object-name- 
array is updated. If this is the first (or only) target in the designated one hundred 
meter grid square, the update is accomplished by making a new object, and 
setting the object-name-array element equal to the new object’s integer “name.” 
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If the array shows that some other target is already in that particular piece of 
terrain (i.e. the object-name-array element is non-zero), the current target is just 
added to the object specified by the “name” in the array. Once this has been 
done for each target, this array is available for the display terrain module. 
Display terrain checks the array as it draws each square of the terrain to see if 
any targets should be drawn. If so, it calls the indicated target object just after it 
has drawn the one hundred meter grid square on which the target(s) rests. Note 
that this causes the target (s) to be drawn at the correct time for the painter’s 
algorithm. The correct place to draw the target still must be specified by the 
transformation commands within the target object. 

In some cases it is necessary to draw a target more than once. Targets that 
straddle a one hundred meter grid square boundary must be drawn on top of both 
(or possibly all four) grid squares in order to avoid being partially obscured by 
whichever grid square is drawn last. (The target must be drawn immediately after 
the grid square on which it rests to ensure that the target will be obscured when 
it should be, by terrain drawn in the foreground.) Since the calculation of 
boundary intersection involves several trigonometric functions and an allowance 
for the distance between the center of the tank and its boundaries (which varies 
with the direction of the tank), a simplifying algorithm is used. If the tank is close 
enough to a boundary that the most distant part of the tank might cross the 
boundary (see tanks A and B in Figure 7.3), the target object is also drawn after 
the adjoining grid square (s). 
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Figure 7.3 - Boundary Conditions 
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The one hundred meter grid square is essentially divided into three areas: 
the middle, its sides, and its corners. In the middle, the tank cannot overlap any 
other grid square. On the sides, the tank may overlap one adjoining grid square, 
and in the corners, the tank may overlap three adjoining grid squares. The 
reference point on the tank (the position the X, F, and Z coordinates refer to) is 
located at the very center of the tank. The tank is thirty feet long, so the most 
distant parts of the tank are within a fifteen foot radius of the tank’s reference 
point. The lines that mark the side and corner areas are thus fifteen feet inside the 
borders of the grid square. Once the tank’s reference point is within these areas, 
it is potentially obscured by the later drawing of the adjacent grid square(s). It 
might not be obscured if it is paralleling a side, for example, but the overhead of 
drawing it twice (or even four times) when it does not need to be is smaller than 
the overhead of the calculations to determine if the position and direction of the 
tank have it actually crossing one or more edges. 

The repeated drawing is accomplished by adding a “new” target to the array 
of target objects. The “new” target object is drawn at the exact same location in 
the three-dimensional terrain, but it is drawn after a different one hundred meter 
grid square, so it will have different target object array indices, and be in a 
separate target object, even though the two (or four) targets drawn will overwrite 
each other and produce a single image. 
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VIII. CULTURAL FEATURE INTEGRATION 



The addition of cultural features add much to the realism of the displayed 
scene. They also provide valuable landmarks from which a person observing the 
scene can geographically orient himself. This chapter covers the addition of one 
type of cultural feature, roads, to the FOG-M simulation. Roads were chosen as 
the first feature to add because of the special problems associated with their 
implementation, the ease of extracting their locations from contour maps, and the 
visual impact added to all parts of the scene due to their wide-ranging locations. 
Three areas will be discussed: (l) the format of the external data file that contains 
the road’s locations, (2) the process of mapping the roads onto the existing 
terrain, and (3) the integration of the roads into the terrain display loop. 

A. EXTERNAL DATA FILE FORMAT 

The data being used in the simulation was obtained by manually extracting 
the roads’ positions from a DMA Topographic Center (DMATC) contour map of 
the area. Although this data is available in the DMA’s Digital Feature Analysis 
Data (DFAD) file, the software necessary to access it was not available. The road 
data file’s format is such that the DFAD data can be easily used when the access 
software is developed. 
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Figure 8.1 shows a segment of the file containing data for two roads along 
with a diagram, showing their locations within the terrain. Each road entry is 
composed of three parts. The first part is the width of the road in feet. Next is 
an integer N, where N is the number of data points used to digitize the road. 
Third is a set N coordinate pairs, where each pair represents the location of a 
digitized point along the road’s centerline. The first coordinate of the pair is the 
east-west location of the point. It is measured in feet from the western terrain 
boundary. The second coordinate of the pair is the north-south location of the 
point, measured in feet from the southern terrain boundary. All the data is stored 
as ASCII text, which facilitates editing bf the data using any text editor. The 
DFAD data file also contains road width information (in meters) and stores roads 
as a series of digitized points. The major difference is that DFAD’s points are 
stored as latitudes and longitudes, which need to be converted before they can be 
used in the simulation. [Ref. 9] 

B. CONSTRUCTION OF THE ROAD POLYGONS 

Knowing the width and centerline locations for the road, the next step is to 
construct the polygons which represent it. Although, this seems like a simple 
procedure, it is complicated by the fact that the road must follow the rise and fall 
of the terrain. Also, in order for hidden surface elimination to occur, the road 
must be divided at the gridsquare boundaries so that each piece can be drawn 
along with its corresponding gridsquare. The result is that the road must be 
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Figure 8.1 External Data File Format 
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broken into many planar polygons, where each polygon is a portion of the road 
that overlays one of the terrain triangles within a gridsquare. Figure 8.2 
illustrates this division and defines some of the terms used in the description that 
follows. The high level pseudocode for processing the road data and constructing 
the planar polygons is shown in Figure 8.3. As the pseudocode shows, each road 
is processed a segment at a time. For each segment 

- The end points of the segment’s left and right side are calculated. A look- 
ahead to the next road segment is done, allowing the ends of adjacent 
segments to be calculated so that they meet cleanly. 

- A bounding box, which contains all the gridsquares intersected by the 
segment, is constructed. 

Next, for each gridsquare in the bounding box, the road segment is divided into 
the road-polygons at the gridtriangle boundaries. Note that all the vertices of the 
road-polygons fall into one of five types; 

- The intersection of a segment’s left side with the side of a gridtriangle. 

- The intersection of a segment’s right side with the side of a gridtriangle. 

- A gridsquare’s cornerpoint that is contained within the road segment. 

- An endpoint of the left side of the road. 

- An endpoint of the right side of the road. 

The road polygon is constructed by finding all the above vertices which exist, and 
ordering them counterclockwise. The counterclockwise ordering is necessary for 
backface polygon removal to take place. The intersections only define the A' and 
Z coordinates or the vertices. The Y (elevation) coordinate is found by 
interpolating between the terrain’s elevation at the three corners of the 
corresponding gridtriangle. 
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Figure 8.2 Constructing the Road Polygons 
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While more data in the road data file do 
read width offroad 
read number_of_points 

read segment's start coordinate pair (seg jstart) 
read segment’s end coordinate pair (seg^end) 

for i = 3 to number jof_points + 1 do 

if i ^ number_of_points then 

read the next segment’s end coordinate pair (next_seg_end) 
else 

next_segjend_x ^ seg_end_x 
next seg end z seg end z 
endif 

calculate the start and end points for the segment’s left and right side 
(left start, left_end, right^start, right_end) 

calculate a bounding box around the road segment 

for each gridsquare within the bounding box do 

Construct the polygon which overlays the gridsquare’s northern triangle 
Add the polygon to the road object associated with this gridsquare 

Construct the polygon which overlays the gridsquare’s southern triangle 
Add the polygon to the road object associated with this gridsquare 
right start ^ right jend 

endwhile 



Figure 8.3 Pseudocode for Constructing Road Polygons 



C. INTERNAL ROAD-POLYGON STORAGE 

A global, two-dimensional array of graphicalobjects, named road, is used to 
store the road polygons. Each entry in the array corresponds to the pieces of road 
that lie within a gridsquare. An object is created when the first road-polygon is 
constructed for a gridsquare, with subsequent road-polygons being inserted into 
the already existing object. Since the roads are static in nature, the use of objects 
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does not present the dynamic memory allocation problems associated with their 
use in storing targets (see the Simulator Performance Section of Chapter VI). As 
each gridsquare of the terrain is drawn, a check is made to see if a road object 
exists for that square. If one does exist, the associated road-polygons are drawn 
immediately after the terrain. This insures that hidden surface elimination occurs 
for the roads as well as the terrain. A photograph of terrain which includes some 
sections of roads can be seen in Chapter VII, Figure 7.1). 



88 



IX. FOG-M SIMULATOR USER’S GUIDE 



A. OVERVIEW 

This section of the report is a user’s guide to running the FOG-M simulator. 
The simulator was built to be largely self documenting. Instructions are clearly 
displayed on the screen, including diagrams which serve as a reminder of the 
functions of the various controls. A knowledge of the logon procedure for the 
IRIS workstation and the basic commands of the UNIX operating system is 
assumed. 

B. STARTING THE SIMULATION 

To start the simulation, logon to the IRIS workstation and use the UNIX cd 
command to change to the directory containing the simulation. Currently the 
simulation is in the directory /work/ terrain. Therefore issue the command: 

cd /work/terrain 

Next, start execution of the simulation by typing the command fogm. A 
welcome screen will appear on the display as shown in Figure 9.1. Pressing all 
three of the mouse buttons simultaneously will stop the program and return 
to the UNIX command level. This option of pressing all three buttons to exit is 
available at any time during the execution of the program. Pressing the middle 
mouse button advances the display to the next screen of instructions. When the 
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Figure 9.1 The Welccme Screen 



user has advanced through the welcome screen and the two instruction screens 
(Figures 9.2 and 9.3) he is presented with a display showing a two-dimensional 
contour map. This is the prelaunch phase of the simulation. 

C. PRELAUNCH CONTROLS 

The purpose of the prelaunch phase is to allow the user to designate a missile 
launch position and a suspected target location position. In effect, the user 
describes an initial flight path for the missile. 

1. The Prelaunch Display 

The prelaunch display is divided into three sections as shown in Figure 
9.4. The upper right corner of the display contains an instruction box which 
summarizes the functions of the mouse buttons for this phase. The lower right 
corner contains a prelaunch statistics box. The meanings of the various items 
within the statistics box are explained below. The majority of the display is 
occupied by a two-dimensional contour map. Each of the square grids on the 
contour map represents a one square kilometer area. The colors on the map can 
be interpreted as follows. Green areas indicate terrain that is covered with 
vegetation that is greater than one meter high. Brown areas indicate terrain 
where the vegetation is less than one meter high. Within each of the color 
categories, the elevation of the terrain is indicated by the intensity of the color, 
with the brighter colors representing the higher elevations. 
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Figure 9.2 The First Instruction Screen 
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Figure 9.3 The Second Instruction Screen 




PRE-LMMCH INSTi^TIONS 
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2. Selecting the Launch Position 



The launch position must be selected first. To select the launch position, 
use the mouse to move the red arrow cursor to the desired location on the contour 
map. As the cursor is moved, the UTM coordinates of the current cursor location 
are shown in the Launch Position field of the statistics box. These coordinates 
can be used when a more accurate selection of the launch position is required than 
is obtainable from the contour map alone. When the cursor is in the desired 
position, press the left mouse button to lock in that position. A blue circle will 
appear on the contour map showing the position selected and the workstation will 
“beep,” confirming the selection. The launch position can be changed any time 
before the launching of the missile by simply moving to the new desired location 
and pressing the left mouse button. 

3. Selecting the Target Position 

The target position can only be selected after a launch position has been 
set. After the launch position has been selected, moving the cursor over the 
contour map produces the following effects: 

- The UTM coordinates of the current cursor position are shown in the Target 
Location field of the statistics box. 

- A “rubber band” line is drawn on the contour map from the launch position 
to the current ctirsor location. This line represents the flight path the missile 
would take if the current cursor position was selected as the target location. 

- The direction and length of the flight path represented by the above line are 
displayed in the statistics box in the Heading and Distance fields respectively. 

Once the cursor is at the desired target location, press the right mouse button 
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to lock in the position. A red circle will appear on the contour map showing the 
selected location and the workstation will “beep,” confirming the selection. 

The missile is now ready for launch. The target location can be changed 
any time before launch by simply moving the cursor to the desired new location 
and pressing the right mouse button. 

4. Launching the Missile 

Launching can not take place until both a launch and target location 
have been selected. If the launch and target locations selected are acceptable, the 
missile is “launched” by pressing the middle mouse button. 

If this is the initial launch of this execution of the program, a several 
(three to four) minute delay will follow during which calculations are done to 
construct the upcoming three-dimensional scenes. Again, this delay only occurs 
during the first launch of any execution. Subsequent launches proceed with no 
delay. During this delay, a countdown will appear in the bottom of the statistics 
box. Launch occurs when the countdown reaches zero. 

D. IN-FLIGHT CONTROLS 
1. The In-Flight Display 

After the missile is launched, the display changes to the in-fiight display 
shown in Figure 9.5. The left side of the display contains: 

- A three-dimensional view of the terrain as seen from the missile’s camera. 

- A slider bar scale along the bottom edge indicating the camera pan angle. 
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Figure 9.5 The In-Flight Display 






- A slider bar scale along the left hand edge indicating the camera tilt angle. 

- A box in the lower left corner containing either the word DESIGNATE or 
REJECT. The word DESIGNATE in this box indicates that the missile is 
not locked on to a target and is waiting for a command to designate one. 
The word REJECT indicates that the missile Is locked on to a target and is 
waiting for a command to reject that target. 

- Cross hairs used to sight the camera onto a target. 

The upper right corner of the display contains a scaled copy of the contour map 
seen in the prelaunch phase. The red arrow superimposed on the contour map 
shows the missile’s current position (the tail of the arrow) and its direction of 
flight. The red rectangle on the map indicates that area of the terrain that is 
currently being shown in the three-dimensional display. 

The middle right section of the display contains four indicators which 
show the following: 



- The speed of the missile in knots. 

- The direction the missile is traveling in degrees. 

- The height of the missile above ground level (AGL) in feet. 

- The height of the missile above mean sea level (MSL) in feet. 

- A slider bar indicating the zoom setting of the camera in degrees. 

The lower right section of the display contains a summary of the functions 
performed by the mouse and dials. These are explained further below. The in- 
flight phase continues until the missile impacts a designated target or all three 
mouse buttons are pressed simultaneously (to stop the execution of the 
simulation). 
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2. Controlling the Camera 



The ranges and initial values of the camera’s functions are shown in 
Table 9.1. All of the camera’s functions are controlled with the mouse. 

- To pan the camera, move the mouse left or right as needed. 

- To tilt the camera, move the mouse up or down as needed. 

- To zoom in to a tighter field of view, press the left mouse button. 

- To zoom out to a wider field of view, press the right mouse button. 

3. Controlling the Missile Flight 

The missile can be controlled by changing its direction, speed, and 
altitude. The ranges and initial values of each of the flight parameters is shown 
in Table 9.2. The missile flight parameters are controlled by using the dials on 
the iris’s button/dial bo.x (see Figure 9.6). Dial zero (lower left) controls the 
missile's direction, dial one (lower right) controls the missile’s altitude, and dial 
two (above dial zero) controls the missile’s speed. Refer to the display’s control 



TABLE 9.1 CAMERA CONTROL RANGES AND INITIAL VALUES 



Control 


Range 


Initial Value 


Maximum 


Minimum 


Pan 

Tilt 

Zoom 


25 degrees right 
25 degrees down 
55 degrees 


25 degrees left 
15 degrees up 
8 degrees 


0 degrees 
15 degrees down 
55 degrees 



TABLE 9.2 MISSILE CONTROL RANGES AND INITIAL VALUES 



Control 


Range 


Initial Value 


Maximum 


Minimum 


Altitude 

Speed 

Direction 


10,000 MSL 
400 kts 
359.9 degrees 


200 AGL 
0 kts 
0 degrees 


200 AGL 
200 kts 

From prelaunch 
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summary box for a reminder of each dial’s purpose and location during flight. 
The controls are used as follows: 

- Direction of flight - Turning dial zero clockwise turns the missile to the 
right. Turning it counterclockwise turns it to the left. The missile will move 
freely through the 360 degree mark so that, for example, turning the missile 
right two degrees from a heading of 359 degrees will produce a heading of 
001 . 

- Altitude - Turning dial one clockwise increases the missile’s altitude up to 
the maximum of 10,000 feet MSL. Turning the dial counterclockwise 
decreases the missile’s altitude. The simulator will not allow an altitude to 
be selected that is less than 200 feet above ground level. 

- Speed - Turning dial two clockwise increases the missile’s speed, while 
counterclockwise decreases the speed. 

4. Designating and Rejecting Targets 



The middle mouse button is used to designate (lock on to) and reject 
(release the lock on) targets. When the missile is not locked on to a target the 
word DESIGNATE will appear in the lower left corner of the display. To 
designate a target, center the target within the cross hairs and press the middle 
mouse button. In order for the missile to lock on, some portion of the target 
must be in the center of the cross hairs. If the designation is successful, the 
workstation will '^beep” and word REJECT will appear in place of the word 
DESIGNATE on the display. Once a target is designated the missile will 
automatically adjust its heading and altitude to home in on the selected target. 
An explosion is displayed after impact with the target occurs. The user is then 
returned to the prelaunch phase of the simulation to begin another launch. 
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A locked on target can be rejected and missile flight control returned to 
the user by pressing the middle mouse button any time before impact with the 
target occurs. The workstation will respond with a “beep” and the 
reject /designate box will again show the word DESIGNATE. The missile is now 
ready to accept the designation of a new target. 
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X. CONCLUSIONS AND RECOMMENDATIONS 



A. LIMITATIONS 

There are several limitations to the flight simulator presented in this study. 
First, a trade-off had to be made between resolution and frame update (display) 
speed. Even though data was available at a resolution of twelve and one-half 
meters, the simulator uses one hundred meter resolution in order to achieve an 
acceptable frame update rate. 

Second, the simulator’s flight is confined to a ten kilometer square area. Any 
ten kilometer square area of the DTED file can be used during a run of the 
simulation, but the simulator must be exited before switching to a new area. This 
limitation is not too restrictive for the current range of the FOG-M, but may be 
inadequate if the range of the missile is increased as planned. 

Third, road data is available in a format usable by the simulator for only one 
10 kilometer square area. Since access routines were not developed for the DFAD 
data file, roads must be digitized by hand. 

Fourth, the simulator does not model any of the missile’s flight dynamics. As 
stated earlier, this limitation was imposed only because of development time 
constraints. It is felt that the dynamics can be acceptably modeled without 
adversely affecting the performance. 
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B. FUTURE RESEARCH AREAS 



A follow-on to this project, which will provide more realistic targets and 
allow viewing of the scene as seen from inside any of them, is currently underway 
at the Naval Postgraduate School. The project’s plans are to use the Ethernet to 
allow several workstations to take part in the simulation simultaneously. Each 
workstation will control one weapon (a target or the missile) and its monitor will 
display the scene as viewed from that weapon. 

Work is also underway at the Naval Postgraduate School in the use of 
digitized photographic images on the IRIS. This work could possibly be 
incorporated into the FOG-M project through the use of digitized target images, 
digitized cultural features, or digitized textures for the terrains. 

Another possible research area is the addition of various environmental effects 
into the simulation. These include clouds, smoke, and rain, which affect the 
camera’s view by reducing visibility, and also dust, which aids the missile 
operator in acquiring moving targets. 

Much work could be done in the area of the missile’s flight dynamics. The 
goal would be to provide an acceptably accurate model without too much of a 
sacrifice in speed. 

C. SUMMARY AND CONCLUSIONS 

The project has proven the practicality and feasibility of building a low-cost 
flight simulator with commercial, off-the-shelf hardware. With a relatively small 
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investment of time and funds, a simulator with significant capabilities was 



developed. As the speed and power of graphics hardware 
realistic displays at faster update rates will be possible. 



increases, even more 
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APPENDIX A - MODULE DESCRIPTIONS 



BUILD ROAD. C 

Input: None. 



Output: None. 

Side Effects: Modifies the global array road^ an array of graphical objects, where 

each object contains the polygons representing the road in a 
particular gridsquare. 



Description: Build road reads the file road width and centerline information 

from the file Road. data and constructs polygons which represent 
the road. The polygons are stored in the array of graphical objects 
road. A more detailed discussion of building the roads is contained 
in Chapter VIII. 



BUILDTERRAIN.C 



Input: 

Output: 

Side Effects: 
Description: 



None. 

None. 

Buildterrain modifies the global arrays savetriangle and gridcolor . 

Buildterrain reads terrain height information from the global array 
gridpixel and constructs the terrain as a set of planar triangles. 
The details of constructing the triangles and the format of the 
savetriangle and gridcolor arrays can be found in Chapter VI. 



COLORRAMP.C 



Input: The inputs to colorramp are two booleans, greyscale and init. If 

greyscale is TRUE, the terrain, sky, and target colortable entries 
are defined in shades of grey to produce a black-and-white image. 
If greyscale is FALSE, the terrain colors are green, the sky is blue, 
and targets are brown. Init is set to TRUE when this routine is 
initially called, so that every entry in the colortable is defined, 
including those for terrain, sky, targets, and writemasked lines on 
top of the contour maps. Should the display be switched between 
color and black-and-white, only the terrain, sky, and target entries 
need to be redefined, which is what happens when init is FALSE. 



Output: None. 

Side Effects: Colorramp changes the system’s colortable, and thus determines 

the colors that appear on the display for the images drawn by 
other routines. 
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Description: 


Colorramp is called by the main program fogm as part of the 
initialization that takes place before the flying loop is entered. At 
that point, greyscale is set to its default value (usually FALSE, 
indicating color images) and init is TRUE. The readcontrols 
routine also calls colorramp to toggle the display image between 
color and black-and-white, based on the position of one of the 
dials. This call is made with the desired value for greyscale and 
with init FALSE. Colorramp uses the IRIS routine mapcolor to 
directly update the colortable for the contour map colors, and calls 
the user written routine gammaramp to define appropriately 
shaded ranges of the greens and browns (or greys) used for the 
terrain and targets. 



COMPASS. C 

Input: Compass takes as input a float, direction, which is an angle in 



Output: 


radians. 

Compass returns a float which is the compass direction in degrees 
corresponding to the input direction. 


Side Effects: 


None. 


Description: 


The function Compass converts an radian angle measured using 
the standard mathematical convention, and converts it to a degree 
angle measured using the standard navigational convention. 



DISP TERRAIN.C 



Input: 


Display terrain takes eleven inputs: the X, Y, and Z, coordinates 
of the missile position VX, VY, and VZ\ the X, Y, and Z 
coordinates of the camera’s look-at position PX, PY, PZ; the field 
of view angle (camera zoom value), FOVY; and the X and Z 
ranges of gridsquares to be displayed, FIRST X, FIRST Z, 
LAST X and LAST_Z. 


Output: 

Side Effects: 


None. 

None. 


Description: 


Disp terrain outputs a frame of the terrain scene to the monitor 
using a hidden surface algorithm. The scene contains terrain, 
roads, and targets. Details of the hidden surface algorithm can be 
found in Chapter VI. 
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DIST TO LOS.C 



Input: 



Output: 

Side Effects: 



Dist to los takes seven inputs: the A", F, and Z coordinates of the 
start of a line segment; the A, F, and Z coordinates of the end 
point of a line segment; and three dimensional array, pt^ which 
contains the coordinates of a point. 

Dist_to_los returns a float which is the perpendicular distance 
from the input point, pt^ to the input line. 

None. 



Description: 



Function which computes the perpendicular distance from a point 
to a line in three-space. 



DO BOUNDARY. C 

Input: Do boundary takes the following inputs: 

- An integer Bound type which is interpreted as: 

0 - a diagonal boundary 

1 - a horizontal boundary 

2 - a vertical boundary 

- An integer which triangle that is interpreted as: 

0 - the lower triangle of the gridsquare. 

1 - the upper triangle of the gridsquare. 

- The indices, xgrid and zgrid^ of the gridsquare for which the road 
is being constructed. 

- The coordinates of the start point of the boundary stored in a 
three dimensional array, bound start. 

- The coordinates of the end point of the boundary stored in a 
three dimensional array, bound end. 

- The coordinates of the start point of the left side of the road 
stored in a three dimensional array, left start. 

- The coordinates of the end point of left side of the road stored in 
a three dimensional array, left end. 

- The coordinates of the start point of the right side of the road 
stored in a three dimensional array, right start. 

- The coordinates of the end point of right side of the road stored 
in a three dimensional array, right end. 

- A boolean, start corner flag., which is TRUE if the gridsquare 
corner at the boundary’s start is ALREADY in the road polygon 
array, FALSE otherwise. 

- A boolean, end corner flag, which is TRUE if the gridsquare 
corner at the boundary’s end is ALREADY in the road polygon 
array, FALSE otherwise. 

- The partially complete road polygon array, road poly. 
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Output; 


- An integer, vertex cnt^ that is the number of vertices currently in 
the road poly array. 

Do boundary outputs the following: 

- start corner flag (see Inputs for a description) 

- end corner flag (see Inputs for a description) 

- road poly, the road polygon array with the vertices along this 
boundary added. 

- vertex cnt (see Inputs for a description) 


Side Effects: 


None. 


Description; 


Do boundary's purpose is to find all the intersections of the road’s 
left and right sides with the input boundary of a gridtriangle. As 
an intersection is found the point is put into a temporary array. 
After all the intersections are found for the boundary the points in 
the temporary array are sorted then added to the existing 
road poly array. The order of the sorting is such that the resulting 
road poly array will be ordered counterclockwise. See Chapter 
VIII for a detailed description of building the roads. 



EDIT INDBOX.C 

Input; The inputs to edit indbox are the name of the indicator object, the 



Output: 

Side Effects: 


tags within that object for each of the indicators, and current 
values for the following missile parameters: X,Y, and Z position 
coordinates, pan, tilt, and zoom angles, and designate/reject 
status. 

None. 

Since edit indbox changes the indicator object, it has the side 
effect of changing the display when the indicator object is next 
called and displayed. 


Description: 


The indicator object is edited between each display frame so that 
the heads-up display and the indicator box indicators show the 
current values for the missile’s speed, heading, altitude, camera 
pan angle, camera tilt angle, camera field of view (zoom), and 
designate/reject status. The input speed, heading, and MSL 
altitude ( Y position coordinate) are converted to strings for 
display. AGL altitude is calculated as the difference between MSL 
altitude and the elevation of the ground directly below the missile 
as obtained from gnd level with the X and Z position coordinates 
as input. The boolean designate determines whether 

“DESIGNATE” or “REJECT” is printed in the lower left corner 
of the terrain display. Finally, the positions of the tilt, pan, and 
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zoom indicators are calculated from the missile parameters. The 
equations in the code have been simplified to avoid excess 
computation; the derivations are given below. 

The X screen coordinate of the zoom (field of view, or fov) indicator 
is fixed. The y screen coordinate varies from 200 (at 8 fov) to 70 
(at 55° fov). The input missile parameter zoom is in tenths of 
degrees, and thus ranges from 80 to 550. The y coordinate is 
determined from Equation A.l. 



y = 200 - 



zoom 

- 8 

10 



200 - 70 
* 

55-8 



(A.l) 



= zoom * -0.2766 + 222.128 



Likewise, the screen x coordinate of the tilt indicator is fixed, while 
the y coordinate varies from 680 (at +25° tilt) to 50 (at —25° tilt). 
The input missile parameter tilt is in radians, and is converted to 
degrees by multiplying it with the RTOD (Radians TO Degrees) 
constant from the header file fogm.h. The y coordinate of the tilt 
indicator is calculated as shown in Equation A. 2. 

( r 1 680 - 50 

y = 50 +<^ [tilt *DTOR) 25 * 

J 25 25 

(A.2) 

= tilt * 721.92682 + 365 



The pan slider bar is horizontal, so the y coordinate is fixed, and 
the X coordinate ranges from 120 (at —25° pan) to 750 (at +25° 
pan). Like tilt, the pan value is in radians and must be converted 
to degrees. The pan indicator x coordinate is given by Equation 
A. 3. 



a; = 750 




an * DTOR) + 25 



] 



750 - 120 



25 - -25 



= pan * -721.92682 + 435 



(A.3) 
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EXPLOSION. C 



Input: 

Output: 

Side Effects: 
Description: 



FOGM.C 

Input: 

Output: 

Side Effects: 
Description: 



None. 

None. 

None. 

The explosion routine simulates the effect of a missile destroying a 
target by rapidly flashing a succession of red, black, and yellow 
screens. One buffer is kept black to pronounce the flash effect, and 
the other buffer is alternately cleared to red, yellow, red, yellow, 
and red. A short pause with a cleared, black screen is provided 
before the routine exits. 



Fogm is the name given to the main program in the simulator. It 
has no parameters, but gets data from its header files and through 
the readdata routine. Interactive input is also received vial the 
readconirols routine. 

None. 

None. 

The fogm program consists of global variable declarations, local 
variable declarations, system initializations, an active loop, and 
some exit housekeeping. The initialization portion includes reading 
in the DMA elevation data, making network connection (if in use), 
setting the IRIS display configuration, defining the color table 
entries, building all of the graphical objects used in the displays, 
and computing the lighting and position of the polygons used to 
produce the terrain image. Within the active loop is some 
additional initializations and the flying loop. In the active loop 
initializations, the dial and mouse controls are reset to their initial 
defaults, and the display buffers are loaded with the images that 
remain unchanged during flight simulation (the contour map and 
the legend/ instruction box). Control is then passed to the flying 
loop, which produces the flight simulation images until either a 
target is hit or the simulation exit command is received. If a target 
was hit, an explosion is displayed and the pre-launch phase of 
designating launch and target positions is re-entered. If all three 
mouse buttons have been pressed, the display is cleared and 
various system parameters are reset to provide a graceful exit from 
the simulator. 
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The flying loop contains the subroutine calls that produce the 
simulation of flight. First, the mouse and dials are checked for 
control input. Then the targets’, missile’s, and lookat reference 
point’s positions are all updated based on the elapsed time since 
the previous frame and the appropriate speeds. View bounds is 
called to determine which one kilometer grid squares are in view, 
and then the indicators are all updated to show the new control 
values, missile statistics, and view area. The main display routine 
then draws the appropriate sections of the terrain, plus cultural 
features and targets where appropriate. Finally, the updated 
indicator objects are drawn, and the display buffers are swapped to 
display the newly created image. 



GAMMARAMP.C 



Input: The inputs to gammaramp are a correction factor, a color table 

starting index, the number of color table entries (shades) to be 
defined, red, green, and blue intensities for the brightest color to be 
defined, and finally, red, green, and blue intensities for the darkest 
color to be defined. 



Output: None. 

Side Effects: Gammaramp has the side effect of defining entries in the system 

color table. 



Description: Displayed colors do not correspond linearly to the numeric red, 

green, and blue intensity values that are used to produce them. If a 
range of colors (0 .. f colors-l) is defined in the straightforward way 
with a uniform increment, the intensity of the n color (/^) is 
given by Equation A. 4 , and the bright colors will appear more 
widely spaced than the dark colors. 

Maxi — Mini 

I = n * + Mini (A. 4) 

§ colors 



Gammaramp avoids this by using a power function to increase 
spacing between the dark colors’ intensity values and to decrease 
the intensity increment as the colors get brighter. The strength of 
the correction is determined by a value 7, which is constant for a 
given range, but must be experimentally determined for each range 
that differs in color or number of colors. FOG-M uses a 7 value of 
1.5. The intensity of the n color in a gammaramp created table is 
given by Equation A. 5 . 
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GETTGT 

Input: 

Output: 

Side Effects: 

Description: 



^ f colors — 1 j 



* [Maxi — Mini) + Mini 



(A.5) 



POS.C 

The input to get tgt pos is a socket number for Ethernet 
communication (if in use), a boolean indicating designate/reject 
status, the index of the currently designated target, and the 
“name” of the tank object. 

Output is the new X, Y,Z position coordinates of the currently 
designated target. 

Get tgt pos updates several global data structures. It sets the 
number of target images, updates the target position arrays, and 
updates the array of target object names. 

The primary purpose of get _tgt pos is to move the targets in the 
simulation. If the networking capability is in use, the target 
positions for the next frame are received over the network. When 
networking is not in use, targets are moved at a set speed of fifteen 
knots, and reverse course when they reach the boundaries of the 
ten kilometer square terrain area. As explained in Chapter VII, an 
array of graphical objects is defined to match one object per one 
hundred meter square of terrain, and this array is also used as 
booleans to indicate the presence or absence of targets in the one 
hundred meter grid square. Get tgt pos begins by removing each 
target from this array. New target positions are calculated or 
received over the network. If one of the targets has been “locked- 
onto,” its new position is returned to be used as the current aim 
point for the missile. This is easily determined if networking is off 
because the designated target’s index remains the same and the 
new position can be directly accessed. The index correspondence is 
not guaranteed when networking, so the index of the new target 
whose coordinates are closest to the old targeted point is used. 

Targets that straddle a one hundred meter grid square boundary 
must be drawn on top of both (or possibly all four) grid squares in 
order to avoid being partially obscured by whichever square is 
drawn last. (The target must be drawn immediately after the grid 
square on which it rests to ensure that the target will be obscured 
when it should be by terrain drawn in the foreground.) Since the 
calculation of boundary intersection requires several trigonometric 
functions plus an allowance for the distance between the center of 
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the tank and its boundaries (which varies with the direction of the 
tank), a simplifying algorithm is used. If the tank is close enough 
to a boundary that the most distant part of the tank might cross 
the boundary, the target is also drawn after the adjoining grid 
square(s) (see Figure 7.3). This is done by adding a ^^new” target 
to the array of target objects. The ‘^new” target object is drawn at 
the exact same location in the three-dimensional terrain, but it is 
drawn after a different one hundred meter grid square, so it will 
have different target object array indices, and be in a separate 
target object. 

After all of the targets (originals and boundary copies) have 
updated positions and target object array indices, objects are 
added to the target object array as described in Chapter VII. This 
array is then used by the terrain display routine to actually draw 
the targets. 



GND LEVEL. C 

Input: Grid level takes as inputs the A" and Z coordinates of the point for 

which the elevation is desired. 



Output: Grid level returns a float which is the elevation at point A" and Z. 

Side Effects: None. 

Description: Gnd level computes, through interpolation, the scaled elevation of 

any point within the terrain boundaries. A calculation is done to 
determine which gridtriangle contains the point. Then, using the 
known elevations at the vertices of the triangle, the elevation of the 
point is found. 



IN THIS POLY.C 

Input: In this poly takes the following inputs: 

- An array of points, polygon^ which define a polygon. (Note: only 
the X and Z coordinates of the points are used, the Y value is 
ignored). 

“ An integer, num vertex, that is the number of vertices in 
polygon, 

- A point, pnt, that is to be tested. (Note: only the X and Z 
coordinates of the point is used, the F value is ignored). 

Output: In this poly returns a boolean which is TRUE if pnt is inside the 

polygon defined by polygon. FALSE otherwise. 



114 



Side Effects: 


None. 


Description: 


In this poly is a function which tests whether a point is inside a 
given polygon, where both the point and the polygon are in the XZ 
plane. The algorithm used constructs a bounding box around the 
polygon. If the point lies outside the bounding it obviously can 
not be inside the polygon. If the point lies inside the bounding box 
a further test is made. A line is constructed from a point outside 
the bounding box to the point to be tested. Each of the edges of 
the polygons are then tested to see if they intersect the constructed 
line and a count is kept of the number that do intersect. The 
point lies inside the polygon if and only if the constructed line 
intersects an odd number of the polygon’s edges. 



INITCTRLS.C 

Input: Init ctrls takes as inputs the initial altitude of the missile, in feet; 



Output: 


the initial heading of the missile in degrees; and a boolean, 
greyscale^ which is TRUE if greyscaled terrain is to be displayed 
and FALSE if color terrain is to be displayed. 

Init ctrls has as outputs the initial pan angle of the camera in 
radians; the initial tilt angle of the camera in radians, and the 
initial zoom setting of the camera in tenths of a degree. 


Side Effects: 


The MOUSEX, MOUSEY, DIALO, DIALl, DIAL2, and DIALS 
valuators are set as a result of calling this routine. 


Description: 


Init ctrls'^s purpose is to initialize the mouse and dial valuators 
used for the operator controls. The initial altitude, heading, and 
greyscale valuator settings are passed in as inputs. The pan, tilt, 
and field of view settings are read from an ^’include*^ file and their 
values passed back as outputs. 



INIT IRIS.C 

Input: None. 



Output: 

Side Effects: 


None. 

Calling this routine sets the Iris attributes and configures the Iris. 


Description: 


Init iris accomplishes the following: it puts the Iris into 

doublebuffer mode, sets the chunksize (the minimum memory 
increment used in objects), sets the monitor type to either NTSC 
or HZ60, and enables backface polygon removal. 
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INITTGTS.C 
Input: None 



Output: 

Side Effects: 


None. 

Init tgts always initializes the global target object array to all 
zeros. If target data is not being received over the network, 
init tgts also defines ten targets by setting initial values in the 
global target counter, target position array, and target direction 
array. An auxiliary function init tgt is used to perform the actual 
update of the global arrays. 



INTERP ELEV.C 

Input: Interp elev takes three inputs, each an array of X, Y, and Z 



Output: 


coordinates, representing a point. One array is the start point of a 
line, the second array is the end point of a line, and the third array 
is a point along the line. 

Interp elev returns a fioat that is the elevation value of the point 
along the line. 


Side Effects: 


None. 


Description: 


Interp elev returns a float which is the linear interpolation of the 
Y (elevation) coordinate of the point along the line, based on the 
elevations at the start and end points of the line. 



LIGHT ORIENT.C 

Input: Light orient takes as inputs the following: 



Output: 


- An array of coordinates for the polygon. 

- An integer, num coords, the number of coordinates in the 
polygon. 

- The A', F, and Z coordinates of a point that is "behind" the 
polygon (an interior point). 

- The A, F, and Z coordinates of a light source. 

- The minimum and maximum color map indices to be used for 
this polygon. 

Light orient returns the color map index of the color to use in 
lighting this polygon. It also reorders the polygon array (if 
necessary) so that the points are ordered counterclockwise. 


Side Effects: 


None. 


Description: 


Light orient computes a lighting for a polygon based on Lambert’s 
cosine law, which states that the intensity of the light reflected 
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from an object is proportional to the cos($), where $ is the angle 
of incidence of the light ray. (see Figure 5.2). Light orient also 
orders the vertices of the polygon in a counterclockwise fashion so 
that backface polygon removal can take place (see the module 
description for npoly orient). 



LINE INTER2.C 

Input: Line inter2 takes the following inputs; 

- An array containing the X and Z coordinates of the start point of 
line one is ignored.) 

- An array containing the X and Z coordinates of the end of 
line one. (Note: a three element array is used, but the second, Y 
coordinate, element is ignored.) 

- An array containing the X, Y , and Z coordinates of the start of 
line two. (Note: a three element array is used, but the second, Y 
coordinate, element is ignored.) 

- An array containing the A, F, and Z coordinates of the end of 
line two. (Note; a three element array is used, but the second, F 
coordinate, element is ignored.) 

Output: Line inter2 returns as outputs: 

- An array containing the X and Z coordinates of the intersection 
of line one and line two. If the lines do not intersect these values 
are undefined not considered in the calculation). 

- An integer which can be interpreted as follows: 

0 - the lines do not intersect. 

1 - the lines intersect, but the intersection uses an 
extension of at least one of the lines past its start or 
end points. 

2 - the lines intersect, and the intersection occurs 
between the input start and end points of both lines. 



Side Effects: None. 



Description: Line inter2 computes the point of intersection between two lines 

in the XZ plane. The type of intersection, as explained above in 
"Output" is also determined. Throughout the routine, three 
element arrays are used for compatibility with other routines. The 
second, F, coordinate is not considered in any of the calculations. 



MAKEINDBOX.C 
Input: None. 
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Output: 



Makeindbox returns a graphical object “name,” tags for editing the 
speed, direction, altitude, and designate/reject readouts, and tags 
for editing the zoom, pan, and tilt indicators. 

Side Effects: None. 

Description: Makeindbox generates a graphical object that contains both the 

indicator box in the middle of the displays on the right side of the 
screen and the “heads-up” display that is superimposed on the 
terrain image (Figure 6.8). The object consists almost entirely of 
straightforward line and character string drawing commands, but 
there are two interesting points. First, within a single object, there 
are two different coordinate systems: one for the indicators 

superimposed on the terrain, and another for the separate indicator 
box. This is accomplished with an ortho2 call for each coordinate 
system, and by bracketing each ortho2 with pushmatrix and 
popmatrix commands. Note that the heads-up display is truly 
superimposed; it is specified in two-dimensional screen coordinates 
as opposed to the three-dimensional terrain coordinates. 

The second interesting aspect is the movement of the slider bar 
indicators. Drawing the indicators as polygons would require a 
sequence of pushmatrix^ translate^ and popmatrix calls for each 
indicator, with movement achieved by editing the translate call. To 
avoid all of this matrix movement and multiplication, the 
“triangle” of the indicator is actually an overlapped line that 
“fills” the triangle by spiraling inwards. The line is drawn relative 
to the indicated point, with each segment of the line specified as 
offsets from that initial point, rather than as absolute coordinates 
(Figure A.l). Movement of an indicator triangle defined in this 
way is achieved by editing the parameters of a move2 call in the 
object, which sets the current graphics drawing position to the 
indicated point on the slider bar scale. Makeindbox is called once 
by fogm before the flying loop is entered, and then the object is 
edited (to update the indicator values) and called (to display it) 
every frame. 



MAKEINSTRBOX.C 



Input: 

Output: 

Side Effects: 



None. 

Makeinstrbox returns the name of an object to fogm. 
None. 
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Figure A. 1 

Indicator Fill using Line Segments 
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Description: 


Makeinstrbox creates the object that produces the display in the 
lower right of the screen (Figure 6.8) during flight simulation. This 
display contains the legend for the FOG-M controls and the flight 
parameters they affect. Makeinstrbox is called once by fogm to 
create the object, and then the object is called twice per flight to 
put the image into each buffer. Note that writemasks are not 
necessary as they are with makemap and makenavbox^ because 
nothing else writes to the instruction box portion of the screen 
during flight. The image thus remains undisturbed in the bitplanes 
despite the changes in other screen areas. 



MAKEMAP.C 

Input: The input to makemap is the globally defined array of elevation 



Output: 


and vegetation values, gridpixeL 

The output from makemap is a graphical object “name,” which is 
returned to fogm. 


Side Effects: 


None. 


Description: 


Makemap generates the object containing the contour map and 
grid that appear full screen during the pre-launch phase, and 
appear in the upper right corner of the screen during flight 
simulation (Figure 4.1). The map is produced using the 
methodology described in Chapter IV. Fogm calls the object 
returned by drawcontour twice, in order to place the map image in 
both buffers. The image is then protected from overwrite by a 
writemask. Fogm also passes the object name to prelaunch, which 
uses it in much the same way as fogm. 



MAKESCREENS.C 

Input: None. 



Output: 


Makescreens returns an array of objects; instruction panel, 
statistics box, flight path between launch and target endpoints, 
and the three welcome screens, plus tags to update the statistics 
and flight path. 


Side Effects: 


None. 


Description: 


Makescreens builds all of the objects (mostly screens of text) that 
are used by prelaunch. 
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MAKETANK.C 



Input: None. 

Output: Maketank returns the name of an object containing a single tank, 

drawn around the origin. 

Side Effects: None. 



Description: Maketank builds a object that consists solely of the drawing 

commands to produce a single tank. The tank is thirty-two feet 
long, ten feet high, and ten feet wide. Its center bottom is at the 
origin (coordinates 0,0,0), with its left side on the plane Z = -5, its 
back on the plane X = -15, its bottom on the plane F = 0, and it 
faces to the right along the positive x axis. For each of the twenty 
polygon faces that make the tank, the X, F, and Z coordinates of 
each polygon vertex are stored in an array, passed to lightorient, 
and then drawn with polf , the filled polygon drawing command. 
Lightorient ensures the vertices are ordered counter-clockwise in 
the array (with respect to an interior point) for backface polygon 
removal, and then calculates the appropriate color for the polygon 
using the same lighting model that is used for the terrain (see 
Chapter V). 



NEAREST TGT.C 



Input: 



Output: 

Side Effects: 



Nearest tgt takes as inputs the X, F, and Z coordinates of the 
missile position, and the X, F, and Z coordinates of the camera’s 
look-at position. (The end points of the line of sight vector). 

Nearest tgt returns as output an integer, tgt idi, which is the 
target index of the target that is closest to the line of sight vector. 

None. 



Description: For each of the existing targets, nearest tgt computes the distance 

between the target and the line of sight vector. It returns the 
index of the target that was found to be closest. In the case of two 
targets which are the same distance apart, the highest index value 
will be returned. 



NPOLY ORIENT.C 

Input: Npoly orient takes as input: 

- An integer, num coords, that is the number of vertices in the 
polygon. 

- An array containing the coordinates of the polygon. 

- The X, F, and Z coordinates of a point that is "behind" the 
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Output: 


polygon (an "interior" point). 

Npoly orient returns as output an integer which is interpreted as: 

1 - the vertices of the polygon are ordered clockwise. 

2 - the vertices of the polygon are ordered 
counterclockwise. 


Side Effects: 


None. 


Description: 


Npoly orient determines if the polygon is ordered clockwise or 
counterclockwise by computing two points: one along the normal 
vector and the other, the same distance from the polygon, but 
along the vector in the direction opposite the normal. Next the 
distance between these points and the "interior" point is 
computed. If the "interior" point is closer to the point along the 
normal vector, the polygon is ordered clockwise, otherwise the 
polygon is ordered counterclockwise. 



PRELAUNCH. C 

Input: The input to prelaunch is two arrays. The first contains objects, 



Output: 


and the second contains tags for editing those objects. 

Prelaunch returns the A', Y, and Z coordinates of the missile’s 
designated launch position, and the initial direction of flight for the 
missile. This direction is returned in both radians and compass 
degrees (Figure 7.1). 


Side Effects: 


None. 


Description: 


Prelaunch first provides three screens of introductory information. 
Each screen is an object defined by makescreens. After those, the 
user is presented with a full screen contour map of the ten 
kilometer by ten kilometer area available for overflight. Mouse- 
selected points define the missile’s initial position and direction of 
flight, and are displayed on top of the map. The map is writemask 
protected, so it is only drawm twice (once for each buffer) even 
though the flight path is repeatedly drawn and erased on top of the 
map. The flight path is made to act like a rubber band between 
the launch and cursor positions by repeatedly editing of the 
positions in the object containing the flight path line drawing 
commands. Once the flight path is confirmed, the launch position 
and heading are returned to the fogm program. 
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RANDNUM.C 



Input: 

Output: 

Side Effects: 



Randnum uses the global random number seed. 

Randnum returns a floating point random number. 

The global seed value used by randnum is updated during every 
invocation. 



Description: Randnum is a linear congruential pseudo-random number 

generator. The algorithm is a modified version of the one given by 
Sedgewick [Ref. 13]. It uses a a special piecewise multiplication 
routine mult to preserve the low-order digits of the newly 
generated seed even in case of overflow. The value returned is the 
new seed, scaled to fall between zero and one, inclusive. The 
random numbers are used in fogm to vary the point on the tank 
that the missile aims for. This simulates the variance in impact 
point that results from the optical homing of the real missile. 



RANDSEED.C 



Input: 

Output: 

Side Effects: 
Description: 



Randseed takes a long integer as input. 

None. 

Randseed updates the global random number seed value. 

The pseudo-random number generator implemented in randnum 
always returns the same string of numbers when it starts with a 
given seed value. Randseed provides the means to change that 
initial seed value so that different program runs will have different 
strings of “random” numbers. 



READCONTROLS.C 



Input: 



Output: 



Side Effects: 



The inputs to readcontrols are the global A, F, and Z random 
offset values for the aim point on the target, the current 
designate/reject status, and the black-and-white versus color 
boolean greyscale. 

All of the user-commanded control values are output from 
readcontrols: missile speed, heading and altitude, camera pan, tilt, 
and zoom angles, plus designate/reject status, greyscale status. 
Readcontrols also returns values for the booleans that control the 
active and flying loops. 

When a target is first designated, readcontrols calls randnum and 
updates the global target aim offsets randx,, randy ^ and randz. 
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Description: 


Readcontrols checks the status of all of the valuators that provide 
input to the FOG-M simulator, and performs scaling, units 
conversion, and immediate processing, as appropriate. It 
determines whether to accept or reject a ‘‘designate” command, 
based on the color index of the pixel at the center of the screen. (If 
a tank is in the crosshairs, the color index will be from the tank’s 
color ramp, and a designate command will be accepted. Otherwise, 
a designate command will be ignored.) 



READDATA.C 
Input: None. 



Output: 

Side Effects: 


None. 

Readdata fills the global array gridpixeL 


Description: 


Readdata opens and reads the values from the terrain elevation 
data file and stores the values in the gridpixel array. Note that the 
elevation data file is arranged in a format as discussed in Chapter 
III. The gridpixel array is arranged in straight rows and columns 
analogous to the geographic positions of the data. 



ROAD BOUNDS. C 

Input: Road bounds takes as input the following: 



Output: 


- Three arrays (p^l, pt2 and pti) containing the X and Z 
coordinates of three points along the centerline of the road. The 
line segment from pt\ to pt2 defines the first segment of the road. 
The segment from pt2 to ptZ defines the next segment of the road. 

- A float, width, which is the width of the road in feet. 

Road bounds returns the following as outputs: - Four arrays 

[left pt\, right ptl, left pt2, and right pt2) which contain the A" 
and Z coordinates of the first segment’s left and right sides. The 
left side runs from left pt 1 to left pt2 and the right side runs from 
right ptl to right pt2. 

- Four integers, first xgrid, first zgrid, last xgrid and last zgrid, 
which are the indices of the bounding box surrounding the first 
road segment (see Figure 8.2). 


Side Effects: 


None. 


Description: 


Given three points along the center line of the road, and the road’s 
width, road bounds computes the start and end coordinates for the 
first segment’s left and right sides. The end coordinates are 
computed as the intersection of the first segment’s left (or right) 
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side with the second segment’s left (or right) side. This insures 
that adjoining segments will meet cleanly. The second function of 
road bounds is to compute a bounding box around the first road 
segment. This box is defined as the row indices of the northern 
and southern most gridsquares that the road segment intersects, 
and the column indices of the eastern and western most gridsquares 
that the road segment intersects (See Chapter VIII for a more 
detailed discussion). 



SORT ARRAY.C 

Input: Sort array takes as inputs: 

- An array of points, puts. 

- An integer that is the number of entries in the puts array. 

- A boolean, which is TRUE if the array should be sorted in 
descending order, FALSE if the array should be sorted in ascending 
order. 

- The index number of the coordinate that is the sort key: 0 for the 
X coordinate, 1 for the Y coordinate, and 2 for the Z coordinate. 

Output: Sort array returns the array puts with the points sorted according 

to the input parameters. 

None. 



Side Effects: 
Description: 



Sort array performs a simple "bubble-sort" of the input points 
according to the input parameters. 



UP LOOK POS.C 

Input: UpJookjpos takes the following as inputs: 

- The heading of the missile in radians. 

- The pan angle of the camera in radians. 

- The tilt angle of the camera in radians. 

- The X, Y, and Z coordinates of the missile’s position. 

- The X, F, and Z coordinates of the locked-on target (if any). 

- A boolean which is TRUE if the missile is locked-on a target, 
FALSE otherwise. 



Output: Up look pos returns as outputs the X, Y, and Z coordinates of the 

camera’s look-at position. 

Side Effects: None. 



Description: Up_look position computes a point along the camera’s line of 

sight. If the missile is locked on a target, the look-at position is the 
locked-on target’s position. Otherwise it is any point along the 
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camera’s line of sight. See Chapter VI and Figure 6.2 for a more 
detailed discussion. 



UP MSL POSIT. C 

Input; Up msl posit takes as inputs: 



Output: 


- The heading of the missile in radians. 

- The speed of the missile in knots. 

- The .Y, F, and Z coordinates of the missile’s position. 

- The wY, F, and Z coordinates of the locked-on target (if any). 

- A boolean which is TRUE if the missile is locked-on a target, 
FALSE otherwise. 

Up msl posit returns as outputs: 

- The new heading of the missile in radians, if it was changed to 
track a locked-on target. 

- The new heading of the missile in degrees measured in the 
compass convention. 

- A boolean which is TRUE if the missile is still flying (has not hit 
a target), and FALSE if the missile has hit the target. 


Side Effects: 


None. 


Description: 


Up msl posit calculates a new missile position for the next frame. 
The new position is either based on the commanded direction, 
speed, and altitude (when the missile is NOT locked onto a target), 
or the commanded speed and the direction to the target (if the 
missile is locked onto a target). For a detailed discussion of the 
routine, see Chapter VI. 



VIEW BOUNDS. C 

Input: View bounds takes as inputs the ^Y, Y, and Z coordinates of the 



Output: 


missile’s position; the A, F, and Z coordinates of the camera’s 
look-at position; and the field of view (zoom) value. 

View bounds returns as outputs the row indices of the northern 
and southern most gridsquares to be drawn, and the column 
indices of the western and eastern most gridsquares to be drawn. 


Side Effects: 


None. 


Description: 


The purpose of view bounds is to construct a bounding box around 
the gridsquares which are to be drawn. The box is constructed by 
extending the line of sight vector down until it intersects the 
minimum elevation plane. The view bounds extends 20 

gridsquares north, south, east, and west of this intersection point. 



126 



If the missile’s position is not within the bounds, the bounds are 
extended to include the missile’s position. For a more detailed 
discussion, see Chapter VI and Figure 6.5 
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APPENDIX B - SOURCE LISTINGS 



BUILD ROAD 



#include ’’stdio.h” 
f include "fogm.h" 

^include "files. h" 

^include "gl.h" 

^include "math.h" 

#define X 0 

^define Y 1 

^define Z 2 

#define DIAGONAL 0 

#define HORIZONTAL 1 
#define VERTICAL 2 

#define LOWER 0 
#define UPPER 1 

build road() 

{ 

extern Object road[99]|99]; 
extern short gridpixel* 100][l00]; 

FILE *fp, *fopen(); 

float road_width; /* road width if feet */ 

int num_pts; /* number of data points 

for the road seqment */ 

int segnum = 0; 
char tempjlOO ; 
int cnt, i, j; 

int vertex cnt, num duplicates; 
float gnd level(); 
float elev; 

float ptljS;, pt2[3j, pt3 3j; 

float nw corner[3], ne corner|3], sw corner|3], se corner[3]; 
float right_ptl[3], right^pt2[3|; 
float left_ptl[3], left_pt2[3]; 

float north bound, south^bound, east bound, west_^bound; 
float delta x, delta z; 
float seg dir; 

int ne flag, nw flag, se flag, sw flag; 
int xgrid, zgrid; 

int first _xgrid, last_xgrid, first_zgrid, last_zgrid; 
float poly 1[10][3]; 

front buffer(TRUE); 

fp = fopen(ROAD FlLE,"r"); 
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while (fscanf(fp, "%e", &road_width) != EOF) { 
fscanf(fp, "%d", &num pts); 
fscanf(fp, "%e %e^\ &ptl[X), &;ptl[Z]); 
fscanf(fp, ”%e %e'^ &pt2 X], <S^pt2[zj); 

delta x = pt2]X| - ptl[X]; 

delta z = pt2[Z] - ptl[Z]; 

seg dir = atan2(delta^z, delta_x); 

left ptl[X] = ptl[X] + (cos(seg_dir + HALFPI)*road_width/2.0); 
right_ptl[X] = ptl[X] -h (cos(seg_dir - HALFPI)*road_width/2.0); 
left_ptl[Z) = ptl[Z] + (sin(seg_dir -f HALFPI)*road_width/2.0); 
right_ptl[Z) = ptl[Z] + (sin(seg_dir - HALFPI) * road_width/2.0); 
for (cnt = 3; cnt <= num pts -)- 1; +-t-cnt) { 
if (cnt <= num pts) { 

fscanf(fp, ”%e %e”, (^pt3[X], &pt3[Z]); 

} 

else { 

pt3[X] = pt2[X]; 
pt3[Z] = pt2[Z]; 

} 

/* print new road segment number on title screen */ 

segnum += 1; 

pushmatrix(); 

ortho2(0.0, 1023.0, 0.0, 767.0); 
viewport (0,1023, 0,767); 

sprintf(temp, "Building road segment: %d%'\ segnum); 
color(BLUE); 

rectf(780.0, 20.0, 1010.0, 30.0); 

color(CYAN); 

cmov2i(780, 20); 

charstr(temp); 

popmatrix(); 

/* determine the boundaries of this road segment * / 
road_bounds(ptl, pt2, pt3, road width, left ptl, right ptl, 
left_pt2, right_pt2, &:first_xgrid, 

&first_zgrid, &last_xgrid, &: last _z grid); 

for (xgrid = first xgrid; xgrid <= last xgrid; H--)-xgrid){ 

for (zgrid = first zgrid; zgrid <= last zgrid; -h-hzgrid){ 
neflag = FALSE; 
nwflag = FALSE; 
sw flag = FALSE; 
seflag = FALSE; 
vertex cnt = -1; 

east bound = (float)(xgrid ^ l) * FT IOOM; 
west_bound = (float)(xgrid) * FT lOOM; 
north_bound = (float) (zgrid -f 1) * FT lOOM; 
south_bound = (float) (zgrid) * FT lOOM; 

sw_corner[X] = west bound; 
sw^corner[Z] = south bound; 
elev — gridpixel[zgrid][xgrid] & elev mask; 
sw_corner[Y] = pow(elev, ALTSCALE); 
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se corner[X] = east bound; 

se corner[Z] = south bound; 

elev = gridpixel[zgridj[xgrid+l] & elev mask; 

se corner[Y] = pow(elev,ALTSCALE); 

nw corner[X] = west bound; 
nw_corner[Z] = north_bound; 
elev — gridpixel[zgrid+l][xgrid] elev mask; 
nw_corner[Y] = pow(elev, ALTSCALE); 

ne corner[X] = east bound; 
ne cornerjZ] — north bound; 

elev = gridpixel[zgrid-f l][xgrid-t-l] &: elev_mask; 
ne_corner[Y] = pow(elev, ALTSCALE); 



/ * determine points of intersection between the left and 

right sides of the road and the eastern grid boundary 
and add these points to the polygon vertex array */ 

do_boundary(VERTICAL, UPPER, xgrid, zgrid, se corner, ne corner, 
left ptl, left^pt2, right ptl, right pt2, &;se^flag, 

&ne flag, polyl, ^vertex cnt); 

/* determine points of intersection between the left and 

right sides of the road and the northern grid boundary 
and insert these points into the polygon vertex array */ 
do_boundary(HORlZONTAL, UPPER, xgrid, zgrid, ne corner, 
nw corner, left ptl, left pt2, right ptl, 
right pt2, <S^ne flag, &:nw flag, polyl, (^vertex cnt); 

/* determine points of intersection between the left and 
right sides of the road and the diagonal and 
insert these pointsinto the polygon vertex array */ 

do boundary(DIAGONAL, UPPER, xgrid, zgrid, nw_corner, se_corner, 
left ptl, left pt2, right ptl, right pt2, &nw flag, 
kse flag, polyl, &vertex_cnt); 

/* remove duplicate entries from the polygon array */ 
num duplicates = 0; 
for (i = 1; i <= vertex_cnt; + + i) { 
if ((polyl[i][0| == polyl[i-l][0j) 

(polylli](2] == polyl|i-l][2D) { 

for (j = i; j < vertex cnt - num_duplicates; -r+j) { 
polyl[j]10| = polyllj+l][0j; 
polylijjjl] = polylij-lj[l]; 
polyl[jji2j = polylij-^lji2]; 

} 

num_duplicates += 1; 

} 

} 

vertex cnt -= num duplicates; 
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if (vertex_cnt > 0) { /* add polygon to grid object */ 
if (road[zgrid][xgrid != 0) { 

editobj(road[zgrid][xgrid]); 

} 

else { 

road[zgrid][xgrid] = genobj(); 
makeobj (road [z grid | [xgrid ] ) ; 

} 

color(ROADGREY); 
polf(vertex_cnt +1, &polyl[0)[0]); 
linewidth(3); 

poly(vertex_cnt + 1, &:polyl[0][0]); 
closeobjO; 

} 

vertexcnt = -1; 
ne flag = FALSE; 
nwflag = FALSE; 
sw flag = FALSE; 
seflag = FALSE; 

/* determine points of intersection between the left and 

right sides of the road and the southern grid boundary 
and insert these points into the polgon vertex array * / 
do boundary (HORIZONTAL, LOWER, xgrid, zgrid, sw corner, 
se corner, left ptl, left pt2, right ptl, 
right pt2, <fcsw flag, &se flag, polyl, <fcvertex_cnt); 

/* determine points of intersection between the left and 
right sides of the road and the diagonal and 
add these points to the polygon vertex array */ 

do boundary(DIAGONAL, LOWER, xgrid, zgrid, se corner, nw corner, 
left ptl, left pt2, right ptl, right pt2, &se flag, 

<fcnw flag, polyl, <fcvertex cnt); 

/* determine points of intersection between the left and 

right sides of the road and the western grid bound 
and add these points to the polygon vertex array */ 

do _boundary(VERTICAL, LOWER, xgrid, zgrid, nw corner, sw corner, 
left ptl, left pt2, right ptl, right pt2, <fenw flag, 

&sw flag, polyl, (fcvertex cnt); 

/* remove duplicate entries from the polygon array */ 

num duplicates = 0; 
for (i = 1; i <= vertex cnt; + + i) { 
if ((polyl[i][0) == polyl[i-l][0]) 

(polyl[i][2| == polyl[i-l][2])) { 

for (j = i; j < vertex_cnt - num_duplicates; ++j) { 
polyl[j]|0] = polyl[j+l][0]; 
polylijjjl] = polylij+ljilj; 
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polylljl(2| = polyllj+l]|2]; 



} 

num_duplicates += 1; 

} 

} 

vertex cnt -= num duplicates; 

if (vertex_cnt > 0) { /* add polygon to grid object */ 
if (road|zgrid)[xgrid] != 0) { 

editobj (road [zgrid] [xgrid]) ; 

} 

else { 

road|zgrid][xgridj = genobj(); 
m akeobj (road i zgrid ] [xgrid] ) ; 

} 

color(ROADGREY); 

polf(vertex cnt -hi, &:polyl[0|[0}); 

linewidth(3); 

poly(vertex_cnt + 1, &;polyl|0][0|); 
closeobjO; 

} 

} 

} 

right_ptl[X] = right_pt2[X|; 
right ptl Z] = right_pt2[Z|; 
left_ptl[X] = left_pt2|X]; 
left_ptl[Z| = left_pt2lZ|; 
ptlLX^ = pt2|X];" 
ptl[Zj = pt2|Z|; 
pt2 X = pt3[Xj; 
pt2'Z| = pt3[Z|; 

} 

} 

fclose(fp); 

frontbufTer (FALSE); 

} 



132 



BUILDTERRAIN 



/* buildterrain.c - this function builds objects representing 1km grid squares 
in 3-D, with each grid square generating 4 objects, identical except for 
order of drawing */ 

^include "gl.h‘* /* get the graphics defs */ 

^include "device. h” /* get the graphics device defs */ 

^include "fogm.h" default constants */ 

^include "math.h" /* math function declarations */ 

buildterrain() 

{ 

/* array of data points to build the terrain */ 
extern short gridpixel|lOO [100]; 

extern float savetriangle[99|[99)l2][3]l3|; 

extern long gridcolor[99][99]; 

extern Object target [99] [99]; 

extern float ground_plane[4][3]; 

extern long gnd plane_color; 

float gnd plane ht; 

Coord trianglel[3][3i, triangle2[3][3]; /* polygon coordinates */ 

short xgrid, zgrid; /* indexes into the grid object array */ 

short endrow, endcol; /* miscellaneous indexes etc * / 

int row, col; 



float ax,ay,az; /* interior point for use in the lightpoly function */ 

float lx,ly,lz; /* position of light source in lightpoly function */ 

/* min and max colormap indexes for lighting the poly */ 
long colormin, colormax; 

/* color index to use returned by the lightpoly function */ 
long colortouse, colorl, color2; 

char temp[50]; /* character string for countdown * / 

float x,y; 

float gammacorr; 

long rampamax, rampamin, rampbmax, rampbmin; 
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int startrow, started, coordidx, vertex; 



lx = 500 * FT lOOM; j* direction of light source */ 
ly = 100000 * FTJOOM; 

Iz = ly; 



frontbuffer(TRUE); /* write to front buffer * / 

/* compute color for ground_plane polygon * / 
gnd plane ht = pow(( float) MIN, ALTSCALE); 
grou"nd_plane[0][0] = -NUMXGRIDS * FEETPERGRID; 
ground_plane[0][l] = gnd_plane ht; 
ground3lane[0][2) = NUMZGRFDS * FEETPERGRID; 

ground_plane[l][0] = 2.0 * NUMXGRIDS * FEETPERGRID; 
ground planeT][l] = gnd plane ht; 
ground"plane[l|[2] = NUxMZGRFdS * FEETPERGRID; 

ground_plane;2][0] = 2.0 * NUMXGRIDS * FEETPERGRID; 
ground_plane 2][l] = gnd_plane_ht; 

ground~plane^2][2l = -2.o"* NUMZGRIDS * FEETPERGRID; 

ground plane 3j[0) = -NUMXGRIDS * FEETPERGRID; 
ground plane;3)[l] = gnd plane ht; 

ground^plane 3l[2] = .2.0”* NUMZGRIDS * FEETPERGRID; 

lightorient(ground plane, 4, 0. 0, 0. 0,0.0, lx, ly,lz, 256, 461, <Ugnd plane color) 

/* compute coordinates and colors for triangles and store in global 
variable savetriangle for later display */ 

for (col = 0; col < 99; -h-hcol) { 

I* print new countdown number on title screen * / 
pushmatrix(); 

ortho2(0.0, 1023.0, 0.0, 767.0); 
viewport (0,1023,0, 767); 

sprintf(temp, ’’Countdown to launch: %d%”, 98 - col); 
color(BLUE); 

rectf(780.0, 15.0, 1010.0, 30.0); 

color(CYAN); 

cmov2i(788, 20); 

charstr(temp); 

popmatrix(); 

for (row = 0; row < 99; -h-f-row) { 

j* choose which color ramp to use so that a checker board 
effect is acheived * ! 
if ((row-rcol)%2){ 

colormin = 256; 
colormax = 461; 



134 



} 

else { 

colormin = 462; 
colormax = 667; 

} 

/* build the polygon */ 

trianglel;0][2] = (float)row * (-41.01) * 8.0; 

trianglel[0)[0] = (float)col * 41.01 * 8.0; 

trianglel[0][l] = pow( (float) (gridpLxel[row][col]&elev_mask) 

, ALTSCALE); 

trianglel[l][2] = (float)row * (-41.01) * 8.0; 

trianglel(l][0] = (float) (col-fl) * 41.01 * 8.0; 

trianglel(l][l] = pow( (float) (gridpixel[rowjjcol-fl]&elev_mask) 

, ALTSCALE); 

trianglel[2](2] = (float) (row -fl) * (-41.01) * 8.0; 
trianglel[2] [O] = (float)col * 41.01 * 8.0; 

trianglel[2][l] = pow((float)(gridpixel[row-f l][col]&:elev mask) 

, ALTSCALE); 

/* copy common vertex values for opposing triangle of grid */ 
for (vertex = 1; vertex < 3; -^--fvertex) { 

triangle2(vertex][0] = trianglel(vertex][0]; 
triangle2[vertex](l] = trianglel[vertex](l]; 
triangle2|vertex][2] = trianglel [vertex] [2]; 

} 

/* change corner coordinate to form opposing triangle of grid */ 
triangle2[0|[2| = (float) (row -fl) * (-41.01) * 8.0; 
triangle2[0][0j = (float)(col-f 1) * 41.01 * 8.0; 

triangle2|0]|l] = pow((float) (gridpLxel|row+l][col-f ij&elev mask) 

, ALTSCALE) ; 

/* compute an interior point for trianglel */ 
ax = trianglel[0][0| + 15.0; 
ay = -10.0; 

az = trianglel[0]|2] -15.0; 

/* light and orient trianglel */ 

lightorien t (triangle 1,3, ax, ay, az, lx, ly,lz, colormin, colormax, &colorl) 

/* compute interior point for triangle2 */ 
ax = triangle2[0][0| - 15.0; 
ay — -10.0; 

az = triangle2[0|(2] -f 15.0; 

/* compute the light for and orient triangle2 */ 

lightorien t(triangle2, 3, ax, ay, az, be, ly,lz, colormin, colormax, &color2); 
/* compute average color for the square */ 



135 



colortouse = (colorl + color2) / 2; 



/* save this triangles color and orientation */ 
for (vertex = 0; vertex < 3; ++vertex) 

for (coordidx = 0; coordidx < 3; -h-hcoordidx) { 
savetrianglejrow] [col] [O] [vertex] [coordidx] = 
triangleljvertexjjcoordidxj; 
savetriangle[row][col][l][vertex)[coordidxj = 
triangle2lvertex|[coordidx|; 

} 

gridcolor[row][col] = colortouse; 



} 

} 

front buffer (FALSE); 

} 
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COLORRAMP 



/* constructs the color ramps to be used for displaying the terrain. 

If greyscale is true, constructs greyscale ramps, else it 
constructs green ramps. */ 

^include "fogm.h" /* fogm constants */ 

colorramp(greyscale,init) 
int greyscale, init; 

{ 

int i; 

/* build two gamma corrected color ramps with slightly offset colors */ 
if (greyscale) { 

gammaramp(l.5,256,205,255,255,255,50,50,50); /* even terrain ramp */ 
gammaramp(l.5,462,205,245,245,245,40,40,40); /* odd terrain ramp */ 
gammaramp(l.5,668,180,235,235,235,30,30,30); /* tank ramp */ 
mapcolor(SKYBLUE,230,230,230); /* sky color */ 

mapcolor(ROADGREY,35,35,35); 

} 

else { 

gammaramp(l. 5, 256, 205, 0,255, 0,0, 50,0); /* even terrain ramp */ 

gammaramp(l,5, 462, 205, 0,245, 0,0, 40,0); /* odd terrain ramp */ 

gammaramp(l.5,668,180,255,165,55,75,55,0); /* tank ramp */ 

mapcolor(SKYBLUE,200,200,255); /* sky color */ 

mapcolor(ROADGREY,35,35,35); 



if (init) { 

mapcolor(l6, 0,70,0); /* set up colors for contour map */ 

mapcolor( 17,0,80,0); 

mapcolor( 18,0,90,0); 

mapcolor( 19,0, 100,0); 

mapcolor(20,0, 110,0); 

mapcolor(21,0,120,0); 

mapcolor(22, 0,130,0); 

mapcolor(23,0,140,0); 

mapcolor(24,0,150,0); 

mapcolor( 25,0, 165,0); 

mapcolor( 26,0, 180,0); 

mapcolor(27, 0,190,0); 

mapcolor(28, 0,2 10,0); 

mapcolor (29, 0,225,0); 

mapcolor(30, 0,240,0); 

mapcolor(3 1,0, 255,0); 

mapcolor(32,75,55,0); 

mapcolor (33, 95, 60,0); 

mapcolor(34,115,70,0); 

mapcolor (35, 125, 76,0); 
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mapcolor(36, 135,83,0); 

mapcolor(37, 145,90,0); 

mapcolor(38, 155,97,0); 

mapcolor(39, 165, 105,0); 

mapcolor(40, 175, 110,0); 

mapcolor(4 1,185, 11 3,0); 

mapcolor(42,190,118,0); 

mapcolor(43,200,127,0); 

mapcolor(44,2l0,135,30); 

mapcolor(45, 225, 145,35); 

mapcolor(46, 240, 155,45); 

mapcolor(47,255,165,55); 

for (i=64; i<128; i+-f-) mapcolor(i,0,0,255); 

for (i=128; i<256; i-^ + ) mapcolor(i, 255,0,0); 

mapcolor(851, 0,150,0); /* set up colors for instruction box * / 

mapcolor(852, 255, 165,55); 

mapcolor(853,95,60,0); 

mapcolor(854, 0,0,0); /* color for indicator box background*/ 

} 

} 
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COMPASS 



/* compute the compass heading in degrees of the input direction. */ 

^include "fogm.h” /* fogm constants */ 

float compass(direction) 
double direction; 

{ 

float compassdir; 

compassdir = RTOD * direction; 
if (compassdir <= 90.0) 

compassdir = 90.0 - compassdir; 

else 

compassdir = 450.0 - compassdir; 
ret urn (compassdir); 

} 
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DISPLAY TERRAIN 



/* Compute which polygons need to be drawn to display the terrain and 
output them in an order such that the polygons farthest from the viewer 
are drawn first and those closest are drawn last. 

Note: Eventhough this seems like a long routine, it is broken into 8 
independent cases based on the direction the camera is looking. 

If you understand one case the others are merely mirror images of the 
algorighm for other octants. */ 

^include "fogm.h" 

^include "math.h” 

^include "gl.h” 

display terrain(vx, vy, vz, px, py, pz, fovy, 
firstxgrid, firstzgrid, lastxgrid, lastzgrid) 

Coord vx, vy, vz, px, py, pz; 
int fovy; 

short firstxgrid, firstzgrid, lastxgrid, lastzgrid; 

{ 

extern float ground_plane|4)[3); 

extern long gnd plane color; 

extern Object road|99][99]; 

extern Object target ■99][99|; 

extern float savetriangle[99j|99)[2][3][3); 

extern long gridcolor[99)|99]; 

double lookdir; 

int threshold, count, startx, startz; 
short xgrid, zgrid; 
float tanval; 
float y; 

if (TV) viewport(0, 474, 0,474); 
else viewport(0, 767, 0,767); 
pushmatrix(); 

color(SKYBLUE); 

clear(); 

ortho2(0. 0,1023. 0,0. 0,767.0); /* outline the screen */ 

color(BLACK); 

recti(0,0,1023,767); 

popmatrix(); 

pushmatrix(); 

perspective(fovy, 1.0, 0.0, 19500.0); 

Iookat(vx,vy,vz,px,py,pz,0.0); 
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/* determine the direction of the line of sight */ 

lookdir = (double)atan2((float)(vz - pz), (float)(-(vx - px))); 

if (lookdir < 0.0) lookdir -f= TWOPI; 

/* lay down the ground plane */ 
color (gnd_plane_color); 
polf(4, ground plane); 

/* put the grid objects through the geometry engine in an order 
based on the lookdir. */ 
if (lookdir > SEVEN QTR PI) 

{ 

/* 8th OCTANT */ 

threshold = (int)(tan(lookdir+HALFPI) -h 0.5); 

count = 0; 
startx = lastxgrid; 
startz = firstzgrid; 
while (startz <= lastzgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid <= lastxgrid) (zgrid <= lastzgrid)) { 

color(gridcolor[zgrid] [xgrid]); 
polf(3,<^savetriangle[zgrid] [xgrid j [O] [O] [O] ) ; 
polf(3,&savetriangle;zgridj[xgridj[l][oj[0]); 

if (road[zgrid][xgridj != 0) callobj(road[zgrid] [xgrid]); 
if (target[xgrid][zgrid| != 0) callobj(target[xgrid][zgrid]); 
/* check if tank should be drawn now */ 

zgrid 1; 
count += 1; 

if (count >= threshold) { 
xgrid += 1; 
count = 0; 

} 

} 



startx -= 1; 
count = 0; 

if (startx < Brstxgrid) { 
startx = firstxgrid; 
startz += threshold; 

} 

} 

} 

else if ((lookdir > THREE_HALVES_PI) && (lookdir <= SEVEN_QTR_PI)) 

{ 
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/* 7th OCTANT */ 

tanval = tan(lookdirH-HALFPI); 

if (tanval == 0.0) 

threshold = 1000; 

else 

threshold = (int)((1.0/tanval) + 0.5); 

count = 0; 
startx = lastxgrid; 
startz = firstzgrid; 
while (startx >= firstxgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid >= firstxgrid) (zgrid >= firstzgrid)) { 

color(gridcolor[ zgrid] [xgrid]); 
polf(3,&savetriangle[zgrid| [xgrid] [0][0][0]); 
polf(3,&savetriangle[zgrid[[xgrid][l][0][oj); 
if (road[zgrid][xgrid] != 0) callobj(road[zgrid][xgridj); 
if (target [xgrid][zgrid] != 0) callobj(target[xgrid][zgrid|); 

xgrid -= 1; 
count += 1; 

if (count >= threshold) { 
zgrid -= 1; 
count = 0; 

} 

} 



startz -h= 1; 
count = 0; 

if (startz > lastzgrid) { 
startz — lastzgrid; 
startx -= threshold; 

} 

} 

} 

else if ((lookdir > FIVE_QTR_PI) && (lookdir <= THREE_HALVES_PI)) 

{ 

/* 6th OCTANT V 

tanval = -tan(lookdir+HALFPI); 

if (tanval == 0.0) 

threshold = 1000; 

else 

threshold = (int)((l.0/tanval) -h 0.5); 



count = 0; 
startx = firstxgrid; 
startz = firstzgrid; 
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while (startx <= lastxgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid <= lastxgrid) (zgrid >= firstzgrid)) { 

color (gridcolorjzgrid] [xgrid]); 
polf(3,&savetriangle[zgrid]|xgrid] [O] [O] [O] ) ; 
polf(3,&savetriangle|zgrid] [xgrid] [ 1 j [O] [O]) ; 

if (road[zgrid| [xgrid] != 0) callobj(road[zgrid] [xgrid]); 
if (target[xgrid|[zgrid] != 0) callobj(target[xgrid][zgrid)); 
xgrid += 1; 
count -\-= 1; 

if (count >= threshold) { 
zgrid 1; 
count = 0; 

} 

} 

startz += 1; 
count = 0; 

if (startz > lastzgrid) { 
startz = lastzgrid; 
startx threshold; 

} 

} 

} 

else if ((lookdir > PI) && (lookdir <= FIVE QTR PI)) 

{ 

/* 5th OCTANT V 

threshold = (int)(-tan(lookdir+HALFPI) + 0,5); 

count = 0; 
startx = firstxgrid; 
startz = firstzgrid; 
while (startz <= lastzgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid >= firstxgrid) && (zgrid <= lastzgrid)) { 
color(gridcolor [zgrid] [xgrid]); 
polf(3,&savetriangle[zgrid] [xgrid] [0][0][0]); 
polf(3,&savetriangle|zgrid][xgrid][l)[0][0]); 

if (road[zgrid] [xgrid] != 0) callobj(road[zgrid][xgrid]); 
if (target[xgrid] [zgrid] != 0) callobj( target [xgrid] [zgrid]); 
zgrid += 1; 
count += 1; 
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if (count >= threshold) { 
xgrid 1; 
count = 0; 

} 

} 



startx += 1; 
count = 0; 

if (startx > lastxgrid) { 
startx = lastxgrid; 
startz += threshold; 

} 

} 

} 

else if ((lookdir > THREE QTR Pl) && (lookdir <= PI)) 

{ 

/* 4th OCTANT V 

threshold = (int) (tan(lookdir^HALFPI) + 0.5); 

count = 0; 
startx = firstxgrid; 
startz = lastzgrid; 
while (startz >= firstzgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid >= firstxgrid) && (zgrid >= firstzgrid)) { 

color (gridcolor [Zgrid] [xgrid]); 

polf (3, <fcsavetriangle [zgrid] [xgrid] [0][0][0]); 

polf(3,&savetriangle[zgrid] [xgrid] [ijjojjo]); 

if (road[zgrid][xgridJ != 0) callobj(road[zgrid][xgrid|); 

if (target(xgrid][zgrid] != 0) callobj(target[xgrid][zgridl) 

zgrid -= 1; 
count += 1; 

if (count >= threshold) { 
xgrid 1; 
count = 0; 

} 

} 



startx H-= 1; 
count = 0; 

if (startx > lastxgrid) { 
startx = lastxgrid; 
startz -= threshold; 

} 

} 
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else if ((lookdir > HALFPI) && (lookdir <- THREE QTR PI)) 

{ 

/* 3rd OCTANT V 

tanval = tan(lookdir-l-HALFPI); 

if (tanval == 0.0) 

threshold = 1000; 

else 

threshold = (int)((1.0/tanval) + 0.5); 

count - 0; 
startx = firstxgrid; 
startz = lastzgrid; 
while (startx <= lastxgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid <= lastxgrid) &;&; (zgrid <= lastzgrid)) { 

color (gridcolor[zgrid] [xgrid]); 
polf(3,&;savetriangle[zgrid|[xgrid|[0][0][0]); 
polf(3,&:savetriangle[zgrid] [xgrid] [ ij jo] [O]) ; 

if (road[zgrid|[xgrid| != 0) callobj(road[zgridj[xgridj); 
if (target[xgrid| [zgrid] != 0) callobj(target[xgrid][zgrid]); 
xgrid += 1; 
count += 1; 

if (count >= threshold) { 
zgrid -h= 1; 
count = 0; 

} 

} 



startz -= 1; 
count = 0; 

if (startz < firstzgrid) { 
startz = firstzgrid; 
startx -h= threshold; 

} 

} 

} 

else if ((lookdir > QTR PI) && (lookdir <= HALFPI)) 

{ 

/* 2nd OCTANT */ 

tanval = “(tan(lookdir-hHALFPI)); 

if (tanval == 0.0) 

threshold = 1000; 

else 

threshold = (int)((1.0/tanval) ^ 0.5); 
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count = 0; 
startx = lastxgrid; 
startz = lastzgrid; 
while (startx >= firstxgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((zgrid lastzgrid) (xgrid >= firstxgrid)) { 

color (gridcolor [zgrid] [xgrid]); 
polf(3,&:savetriangle[zgrid][xgrid][0][0][0]); 
polf(3,&:savetriangle[zgrid] [xgrid] jljjojjoj); 

if (road[zgrid][xgrid] != 0) callobj(road[zgrid] [xgrid]); 
if (target[xgrid][zgrid] != 0) callobj(target'xgrid)[zgrid]); 
xgrid -= 1; 
count += 1; 

if (count >= threshold) { 
zgrid += 1; 
count = 0; 

} 

} 



startz 1; 
count = 0; 

if (startz < firstzgrid) { 
startz = firstzgrid; 
startx threshold; 

} 

} 

} 

else if ((lookdir >== 0.0) &:&: (lookdir <= QTR_PI)) 

{ 

/* 1st OCTANT V 

threshold = (int)(-tan(lookdir+HALFPl) + 0.5); 

count = 0; 
startx = lastxgrid; 
startz = lastzgrid; 
while (startz >= firstzgrid) { 
zgrid = startz; 
xgrid = startx; 

while ((xgrid <= lastxgrid) &:&: (zgrid >= firstzgrid)) { 

color (gridcolor [zgrid] [xgrid]); 
polf(3,&savetriangle[zgrid][xgrid][0][0][0]); 
polf(3,&:savetriangle[zgrid] [xgrid] [l][0|[0]); 

if (road[zgrid][xgrid] != 0) callobj(road[zgrid][xgrid]); 
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if (target[xgrid][zgrid] != 0) callobj(target[xgrid][zgrid]); 
zgrid 1; 
count += 1; 

if (count >= threshold) { 
xgrid += 1; 
count = 0; 

} 

} 



startx 1; 
count = 0; 



} 



if (startx < firstxgrid) { 
startx = firstxgrid; 
startz -= threshold; 

} 

} 

} 

popmatrix(); 
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DIST TO LOS 



^include "gl.h" 

#include ’’math.h" 

float dist_to_los(vx,vy,vz,px,py,pz, point) 

/* compute the distance from the point "point" to the line of sight */ 

Coord vx,vy,vz,px,py,pz; 
float point[3j; 

{ 

float a,b,c; /* direction numbers of line of sight */ 
float d,e,f; 
float dist; 

a = (float)(px - vx); 
b = (float)(py - vy); 
c = (float)(pz - vz); 

d = point[0] - (float)vx; 
e = pointjl] - (float)vy; 
f = point[2) - (float)vz; 

dist = sqrt((up_i(e*c - f*b,2) + up_i(f*a - d*c,2) + up i(d*b - e*a,2))/ 
(upj(a,2) + up_i(b,2) + up_i(c,2))); 

return(dist); 

} 
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DO BOUNDARY 



^include "gl.h" 

^include "math.h" 
^include ”stdio.h” 
^include "fogm.h" 

^define X 0 
^define Y 1 
^define Z 2 

^define DIAGONAL 0 
#define HORIZONTAL 1 
#define VERTICAL 2 

^define LOWER 0 

^define UPPER I 

^define NONE 0 
#define INTERSECT I 
^define PROPER 2 



do boundary (bound type, which triangle, xgrid, zgrid, 
bound start, bound end, left start, 
left end, right start, right end, start corner flag, 
end corner flag, polyl, vertex cnt) 

int bound type, which triangle, xgrid, zgrid; 

float bound start 3], bound end|3], left start|3j, left end[3), 
right^start[3], right^end[3]; 

int *start^corner_flag, *end corner flag; 

float polyl[l0][3]; 

int ^vertex cnt; 



{ 

int test index, cnt, index; 

float bound_right[3], bound_left|3), bound_start_edge[3 
bound end edge [3]; 

float vertex array[l0][3]; 
float road poly[l0]|3]; 
float grid_poly|l0][3]; 

int intersect cnt; 
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int intersect type, decending_sort; 
float upper bound, lower bound; 



float gnd^level(); 
int in_this_poly(); 
intersect cnt = -1; 

/* compute the verticies of the road segment currently 
being worked on */ 
for (index = 0; index < 3; ++index) { 

road poly[0][index] = left start[index]; 
road_poly[l]|index) = left_end[index]; 
road_poly[2||index] = right_end[indexl; 
road poly 3](index] = right start[indexj; 

} “ 

compute the verticies of the grid triangle associated with 
this boundary * / 

grid_poly[0][X] = (float) (xgrid*FT^100M); 
grid poly[0j[Z| = (float)((zgrid-r 1)*FT_100M); 
grid_poly|lj|X] = (float) ((xgrid-fl)* FT _100M); 
grid_poly[l j|Z| = (float) (zgrid*FT lOOM); 
if (which triangle == UPPER) { 

grid _poly[2]iX] = (float) ((xgrid-h 1)*FT_100M); 
grid_poly(2]'Z] = (float)((zgrid + l)*FT_100M); 

} 

else { 

grid_poly!2]'X] = (float) (xgrid*FT_100M); 
grid polyl2] Z] = (float)(zgrid*FT lOOM); 

} 

if (bound type == HORIZONTAL) { 
test index = X; 

} 

else if (bound type == VERTICAL) { 
test index = Z; 

} 

else if (bound type == DIAGONAL) { 
test index = Z; 

} 

if (bound start[test index] < bound endjtest index,) { 
lower bound = bound startitest index]; 
upperjbound = bound endjtest index]; 

} 

else { 

lower bound = bound endjtest index]; 
upper bound = bound startjtest index]; 

} ■ 
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/* determine points of intersection between left and right sides 
of the road and the boundary */ 

line intersect2(bound start, bound_end, right start, right end, 
bound right, &intersect_type); 
if (intersect type — PROPER) { 

/* intersection lies on road line segment, add intersection 
to array */ 
intersect_cnt -\~= 1; 

vertex array [intersect cnt]|X) = bound rightjXj; 

vertex _array[intersect_cnt][Z] = bound_right|Zj; 

vertex array[intersect_cnt]|Y] gnd_level(bound^right|X], 

-bound_right[Z]); 

} 

else if ((intersect^type == INTERSECT) LL 
(in this poly(grid poly, 3, right start)) 

(bound_right|test_index] > lower bound) kk 
(bound rightjtest index] < upper bound)) { 

/* intersection point is beyond the bound of the road’s right 

line segment, but the right start point is inside the polygon so 
add the road’s right start point to the vertex array */ 

intersect cnt 1; 

vertex array [intersect cnt|[X| = right start jXj; 
vertex array[intersect cnt)[Z| = right start[Z|; 
vertex array [intersect cnt)[Y| = gnd level(right start[X], 

-right start[Zj); 

} 

else if ((intersect type INTERSECT) kk 
(in this poly (grid_poly, 3, right end)) kk 
(bound right|test index) > lower bound) kk 
(bound rightjtest index) < upper bound)) { 

/* intersection point is beyond the bound of the road’s right 

line segment, but the right end point is inside the polygon so 
add the road’s right end point to the vertex array */ 

intersect_cnt += 1; 

vertex_array[intersect_cntj[X] = rightendjX); 
vertex_array [intersect cntj[Z| = right endlZ); 
vertex_array[intersect_cnt][Y) = gnd_level(right end[X], 
-right_end[Zj); 

} 

line_intersect2(bound start, bound end, left start, left end, 
bound left, (^intersect type); 
if (intersect type =- PROPER) { 

/* intersection lies on road line segment, add intersection 
to array */ 
intersect_cnt 1; 

vertex_array[intersect_cnt|[X] — bound _left[X); 
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vertex array[intersect cnt)[Z] = bound left[Z]; 
vertex_array[intersect_cnt)[Y] = gnd_level(bound left[X], 
-bound_left[Z]); 

} 

else if ((intersect type == INTERSECT) 

(in_this poly(grid_poly, 3, left_start)) &:&: 

(bound left [test index] > lower bound) 

(bound left[test_index] < upper bound)) { 

/* intersection point is beyond the bound of the road’s left 

line segment, but the left start point is inside the polygon so 
add the road’s left start point to the vertex array */ 

intersect cnt += 1; 

vertex_array[intersect_cnt|[X) = left start[X]; 
vertex array[intersect cnt][Z] = left start[Z|; 
vertex_array[intersect_cnt]| Y] = gnd_level(left_start[X|, 

-left start[Zj); 

} 

else if ((intersect type == INTERSECT) 

(in this poly(grid poly, 3, left end)) 

(bound left[test index) > lower bound) 

(bound left[test index) < upper bound)) { 

/* intersection point is beyond the bound of the road’s left 

line segment, but the left end point is inside the polygon so 
add the road’s left end point to the vertex array * / 

intersect cnt += 1; 

vertex_array|intersect_cnt][X] = left_end X); 
vertex array [intersect cnt][Z] = left endlZ^; 
vertex array[intersect_cnt][ Y] — gnd_level(left_end[X), 

-left end[Z)); 

} 

/* if either of the bound’s end points fall within the bounds of the 
road, add them to the array*/ 

if ((!*start corner flag) (in this poly(road poly, 4, bound start))) { 
/* put in start bound point */ 

*start_corner_flag = TRUE; 
intersectcnt += 1; 

vertex_array[intersect_cntj[X] = bound_start[X); 
vertex array[intersect cnt)[Z] = bound start[Z); 
vertex array[intersect cnt][Y] = bound start[Y); 

} ‘ ' 

if ((!*end_corner_flag) &:&: ( in _this_poly( road poly, 4, bound_end))) { 

/* put in end bound point */ 

*end corner flag = TRUE; 
intersectcnt += 1; 

vertex array [intersect_cnt][X) = bound_end[X); 
vertex_array [intersect cnt] [Z] = bound jend[Z); 
vertex array [intersect^cnt][Y] = bound_end[Y); 
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} 

/* determine the point of intersection between the start and end 
bound of the road and the grid boundary */ 
line intersect2(bound start, bound end, left start, right start, 
bound start edge, &:intersect type); 
if (intersect type == PROPER) { 

/* intersection lies on road line segment, add intersection 
to array */ 
intersect cnt += 1; 

vertex array[intersect cntj[X] = bound start edge[Xj; 
vertex array[intersect cnt][Z] = bound start edge[Z]; 
vertex array[intersect cnt][Y] = gnd level(bound start edge[X], 
-bound start edge|Z]); 

line intersect2(bound_start, bound end, left end, right end, 
bound end edge, &:intersect type); 
if (intersect type == PROPER) { 

/* intersection lies on road line segment, add intersection 
to array */ 
intersect cnt -|-= 1; 

vertex array [intersect cnt] [X] = bound end edge[X|; 
vertex_array[intersect_cnt|[Z| = bound_end_edge[Z|; 
vertex array[intersect cnt][Y] = gnd level(bound end edge[X|, 
-bound_end_edge[Zj); 

} 

/* put the points from the vertex_array into the polyl array in 
the proper order */ 

decending sort = (bound start[test index] != lower bound); 
sort array(vertex array, intersect cnt, decending sort, test index); 

for (cnt = 0; cnt <= intersect cnt; -f+cnt) { 

^vertex cnt -‘-= 1; 

polyl [*vertex cnt][Xj == vertex array[cnt]|X]; 
polyl[*vertex_cnt][Yj = vertexarray [cnt] [Y]; 
poly l[*vertex cnt][Z] = -vertex array[cnt][Z]; 

} 

} 
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EDIT INDBOX 



/* update the control settings of the indicator box */ 

^include ’’fogm.h" 
l^include "gl.h*’ 

edit indbox(indbox, speedtag, headingtag, elevtag, altmsltag, 
zoomtag, tilttag, pantag, desigtag, speed, compassdir, 
vx, vy, vz, pan, tilt, zoom, designate) 

Object indbox; 

Tag speedtag, headingtag, elevtag, altmsltag, zoomtag, tilttag, pantag, 
desigtag; 

float speed, compassdir; 

Coord vx, vy, vz; 

double pan, tilt; 

int designate; 

int zoom; 

{ 

char chspeed|5], chheadingjSj, chelev|5 , chaltmsl[5]; 

float gnd_level(); 

float zoomtic, pantic, tilttic; 

sprintf(chspeed,”%4. Of, speed); /* convert speed to string * / 

sprintf(chheading,*'%3. Of’, compassdir); /* convert heading to str */ 

sprintf(chelev,”%4.0f ,vy - gnd_level(vx,vz)); /* convert elev AGL to str */ 
sprintf(chaltmsl,*’%4.0f ,vy ); /* convert alt MSL to str */ 

/* compute new location for zoom, pan, and tilt indicators */ 

zoomtic = zoom * -0.2766 4^ 222.128; 

tilttic = tilt * 721.92682 + 365.0; 
pantic = pan * -721.92682 -H 435.0; 

editobj(indbox); /* update the indicator display */ 

objreplace(speedtag) ; 

charstr(chspeed); 

objreplace(headingtag); 

charstr(chheading); 

objreplace(elevtag); 

charstr(chelev); 

objreplace(altmsltag); 

charstr(chaltmsl); 

objreplace(zoomtag); 

move2(28.0, zoomtic); 

objreplace( tilttag); 
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move2(42.0,tilttic); 
objreplace( pantag); 
move2(pantic,27.0); 
objreplace(desigtag); 
cmov2i(designate ? 10 : 19,10); 
charstr(designate ? "DESIGNATE" ; 
closeobjO; 

} 



"REJECT"); 
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EDIT NAVBOX 



^include "fogm.h" 

^include "math.h” 

#mclude "gl.h" 

edit navbox(navbox, arrowtag, vx, vz, direction, firstxgrid, firstzgrid, 
lastxgrid, lastzgrid) 

Object navbox; 

Tag arrowtag; 

Coord vx, vz; 
double direction; 

short firstxgrid, firstzgrid, lastxgrid, lastzgrid; 

{ 

Coord arrowx, arrowy, larrowx, larrowy, rarrowx, rarrowy; 

/* compute coordinates of arrow line segments for nav control box */ 

arrowx = vx + cos(direction) * 2.0 FEETPERGRID; 

arrowy = vz - sin(direction) * 2.0 * FEETPERGRID; 

larrowx = arrowx -h cos(direction - 2.3561945) * FEETPERGRID; 

larrowy = arrowy - sin(direction - 2.3561945) * FEETPERGRID; 

rarrowx = arrowx + cos(direction -f 2.3561954) * FEETPERGRID; 

rarrowy = arrowy - sin(direction + 2.3561945) * FEETPERGRID; 

/* update the contour map display with new info */ 

editobj (navbox); 

objreplace( arrowtag); 

move2(vx,vz); 

draw2(arrowx, arrowy); 

draw2 (larrowx, larrowy); 

move2(arrowx, arrowy); 

draw2(rarrowx, rarrowy); 

rect( firstxgrid* FT 100M,-firstzgrid*FT_100M, 

(lastxgrid^ 1)*FT1 oOM, (-lastzgrid-l)*FT_100M); 
closeobjO ; 

} 
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EXPLOSION 



^include ”gl.h” 
explosion() 

{• 

int ij; 

pushviewport(); 
viewport (0,1023,0, 767); 
color(BLACK); 
clear(); 

swapbuffers(); 

color(RED); 

clear(); 

swapbuffers(); 

swapbuffers(); 

color(YELLOVV); 

clear(); 

swapbuffers(); 

swapbuffers(); 

color(RED); 

clear(); 

swapbuffers(); 

swapbuffers(); 

color(YELLOVV); 

clear(); 

swapbuffers(); 

swapbuffers(); 

color(RED); 

clear(); 

swapbuffers(); 

swapbuffers(); 

for (i = 0; i < 100000; 

for (j = 0; j < 10; j-h + ); 
popviewport(); 

} 
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FOGM (MAIN) 



/* fogm.c — an IRIS-2400 program by Doug Smith k Dale Streyle 

It reads in a 10km x 10km section of a terrain map, computes a lighting 
and shading model for the terrain, and allows overflight */ 



^include ”gl.h" 

^include ’’device. h” 
^include ’’fogm.h” 
^include ’’math.h” 
^include ’’get.h” 
^include ’’stdio.h” 
^include ”sys/signal.h” 
^include <sys/types.h> 
#include <sys/times.h> 



/* get the graphics defs * / 

/* get the graphics device defs */ 
/* constants */ 

/* math function declarations */ 
j* monitor type include file */ 

/* used for screen dump utility */ 
/* contains the time sturcture tms 
/* for time calls * / 



V 



short gridpixel[l00][l00]; /* DMA elevation and vegatation data */ 
float savetriangle|99j[99][2 |3 [3]; 
long gridcolor[99][99]; 

Object road[99]|99j; 

Object target[99][99]; 



float ground plane|4][3]; 

long gnd plane color; 

float tgt posiMAX TGTS][3]; 

short tgt_grid_idx[MAX_TGTSj|2j; 

short tgt dir MAX TGTS], tgt total = 0; 

float randx, randy, randz; /* random offsets from tank reference point */ 



int framecnt; 



float min elev, max elev; 
Coord tankx, tanky, tankz; 
float frames_sec[l000][2]; 



main() 

{ 

int greyscale = FALSE; /* FALSE = color, TRUE = greys */ 

int designate; /* boolean indicating desig/reject status */ 

int flying = TRUE; /* boolean controlling flying loop */ 

int active = TRUE; /* boolean controlling main program loop */ 

int nbyte, socket, connect^client(); /* networking variables k subroutine */ 
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struct tms timestruct; /* structure for real-time clock calls */ 

int tgt_idx; /* index of designated target */ 

double direction; /* direction of travel in radians */ 

float speed; /* speed of travel in knots */ 



float compassdir; /* desired direction of travel in compass deg * / 

int fovy = 550; /* field of view in perspective command */ 

double pan = 0.0, 

tilt = -15.0 * DTOR; /* pan and tilt angles */ 

/* contour map, indicator, instruction */ 

Object contour, navbox, indbox, instrbox; 

Object tank, pre 1 obj 7]; 

Tag headingtag, elevtag, speedtag, zoomtag, arrowtag, tilttag, pantag; 
Tag desigtag, altmsltag, pre_l__tag[6j; 

Colorindex unmask; 

Coord vx, vy, vz; /* viewer x y and z coordinates */ 

Coord px, py, pz; /* reference x y z coordinates for lookat */ 

Coord tgtx, tgty, tgtz; /* targeted position on tank */ 
float randseed(); /* random number generator initialization */ 
int frames = -1; 

long seconds, lastseconds, totalseconds = 0; 
int numpolys; 
float elapsed; 
int idx; 

FILE *fopen(), *fp; 

/* first and last x and z indexes of the grid objects to draw */ 
short firstxgrid, firstzgrid, lastxgrid, lastzgrid; 

readdata(); /* read the data file into the gridpixel array */ 

/* get socket number for networking */ 

/*if (NETWORKING) socket = connect_client("npscs-irisl",3); */ 

init_iris(); /* initialize the iris */ 

unmask = (l<<getplanes()) - 1; 
writemask( unmask); 

randseed(times(&:timestruct)); /* seed the random # generator */ 
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init tgts(); /* define targets 

Screen Dump(SCREENDUMP); /* enable screen dumping */ 

billboard(); /* produce intro screen */ 

colorramp(greyscale,TRUE); /* build all color ramps */ 

makescreens(pre 1 obj, pre 1 tag); /* build objects for prelaunch */ 
makemap(<§zcontour); /* build map object */ 

pre l obj [CONTOUR] = contour; 

prelaunch(<^vx, &vy, <§^vz, <§.:direction, <§^compassdir, 

<§«:active, pre 1 obj, pre 1 tag); 

if (active) { 

maketank(&tank); /* build object for a tank */ 

build road(); build the objects that comprise the roads */ 

/* process terrain data to build polygons and compute lighting */ 
buildterrain(); 

/* build object for the navigation display contour map */ 
drawnavbox(<§.£navbox, <§^arrowtag); 

/* build an object for the indicator box */ 

makeindbox(<§^indbox,<§.:headingtag,<§^elevtag,(§^altmsltag,&speedtag, 
zoom tag,<§.i tilt tag, <§^pantag,&desigtag); 



makeinstrbox(<§.:instrbox); /* build object for control instruction box */ 
} /* end of if (active) block */ 

while (active) { 

framecnt = 0; 

/* initialize the operator controls (mouse and dials) */ 
init controls(<§.:pan, <§^tilt, <§^fovy, vy, greyscale, compassdir); 

pushviewport(); 
viewport (0,1023,0,767); 
color(SKYBLUE); 
clear(); 

popviewport(); 

callobj(instrbox); 

callobj(indbox); 

editobj(contour); 

objreplace(STARTTAG); 

viewport (768, 1023,512,767); 
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closeobjO; 

callobj(contour); 

swapbufFers(); 

callobj(instrbox); 

callobj(contour); 

editobj (contour); 

objreplace(STARTTAG); 

viewport (0,768,0,768); 

closeobjO; 

flying = TRUE; j* missile is flying * / 
designate = TRUE; /* a target can be designated */ 

while(flying) { /* until tgt is hit or 3-button exit */ 



/* get values from user contols (mouse and dials) * / 
read controls(<5^designate, ^greyscale, ^flying, ^active, 

&speed, ^direction, &compassdir, &vy, 

&pan, &tilt, &fovy); 

/* calculate which target was closest to the line of 
sight */ 
if (Idesignate) { 

nearest tgt (vx,vy,vz,px,py,pz,&tgt_idx); 

} 

/* update targets’ positions * / 

get tgt posit(socket, designate, tgt idx, <fctgtx, <§^tgty, &tgtz, tank) 
/* update missile position */ 

update_missile_posit(&direction, &compassdir, speed, 
designate, tgtx, tgty, tgtz, 

&:vx, <fcvy, &:vz, &:flying); 

/* update camera lookat position */ 

update look posit(direction, pan, tilt, vx, vy, vz, 

tgtx, tgty, tgtz, designate, &:px, <fepy, <^pz); 

/* determine which polygons need to be drawn */ 
view_bounds(vx, vy, vz, px, py, pz, tilt, fovy, 

<fefirstxgrid, <fcfirstzgrid, <§^lastxgrid, <§^lastzgrid); 

/* edit control display objects to reflect new values */ 
edit_navbox(navbox, arrowtag, vx, vz, direction, firstxgrid, 
firstzgrid, lastxgrid, lastzgrid); 

edit_indbox(indbox, speedtag, headingtag, elevtag, altmsltag, 
zoomtag, tilttag, pantag, desigtag, speed, 
compassdir, vx, vy, vz, pan, tilt, fovy, designate); 



/* display the 3-D view of the terrain as seen by 
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the camera */ 

display terrain(vx, vy, vz, px, py, pz, fovy, 
firstxgrid, firstzgrid, lastxgrid, lastzgrid); 

/* display the control boxes */ 

writemask(SAVEMAP); 

callobj(navbox); 

writemask(unmask); 

callobj(indbox); 

swapbufFers(); 

seconds = times(&timestruct); 

numpolys = (lastxgrid - firstxgrid)* (lastzgrid-firstzgrid) *2; 
elapsed - (float) (seconds - lastseconds)/60.0; 
if ((frames >= 0) (frames < 1000) ){ 

frames_sec[frames][0] = (float)numpolys; 
frames_sec[frames][l] = 1.0/elapsed; 

} 

totalseconds +— (seconds-lastseconds); 
if (totalseconds > 7200) { 

compactifyO; /* do garbage collection every 2 mins */ 
totalseconds = 0.0; 

} 

lastseconds = seconds; 
frames += 1; 

} /* end of flying loop */ 

if (active) { /* explode restart */ 

explosion(); 

prelaunch(&:vx, &:vy, &vz, ^direction, &:compassdir, 
iS^active, pre__l_obj, pre l_tag); 

} 

} /* end of active loop */ 

/* write out performance stats */ 
fp — fopen("speed.data", "w"); 
if (frames > 999) frames = 999; 
for (idx = 0; idx <= frames; + + idx) { 

fprintf(fp,"%.2f %.2f0, fraines_sec[idx][0], frames_^sec[idx][l]); 

} 



162 



/* gracefully exit * / 

if (NETWORKING) close(socket); 

setmonitor(HZ 60 ); 

color(BLACK); 

clear(); 

swapbuffers(); 

clear(); 

gexitO; 

textinit(); 

exit(); 

} I* end of main */ 
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FILES.H 



/* These are the files which contain data for the terrain elevations 
and roads */ 

^define TERRAIN_FILE ^’/work/terrain/tenkmsq.dat" 

^define ROAD FILE "/work/terrain/Road.data" 



FOGM.H 

^define elev mask Oxlfff /* mask to obtain elev value from datum */ 

^define veg mask 0x0007 /* mask to obtain vegatation value from 



shifted datum * / 

#define RD 0 /* code for reading a file in "open" */ 

^define MAX 2800 /* max elev (ft) in contour map */ 

^define MIN 967 /* min elev (ft) in contour map */ 

#define SKYBLUE 4095 /* color index for sky color */ 

^define ROADGREY 850 /* color index for the road * / 



^define DELTAFOVY 50 /* field of view (zoom) increment of 5 deg * / 

^define PI 3.1415927 

#define TWOPI 6.2831853 

#define HALFPI 1.5707963 

#define THREE_HALVES_PI 4.7123889 

#define QTR PI 0.7853982 

#define THREE_QTR_PI 2.3561945 

#define FIVE_QTR_PI 3.9269908 

#define SEVEN_QTR_PI 5.4977871 

^define RTOD 57.29578 /* radians to degrees conversion factor */ 

^define DTOR 0.0174533 /* degrees to radians conversion factor */ 

^define FPS TO KTS 35.525148 /* convert feet per 60th seconds to knots */ 
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^define PANSENS 30.0 /* scale factors (sensitivity) for 

navigaion controls (mouse and dials) */ 



^define 

^define 

^define 

^define 

^define 

^define 



^define 



^define 



#define 

#define 

#define 

^define 

^define 

^define 

^define 

#define 

#define 

^define 

^define 

^define 

^define 

#define 

#define 

^define 

^define 

#define 



SPEEDSENS 20 

TILTSENS 50.0 

DIRSENS 20.0 

MAXLOOKDIST 32808.0 /* maximum distance that the camera can 

look ahead in feet */ 

FEETPERGRID 3280.8 /* number of feet in 1000 meters */ 

ALTSCALE 1.05 /* altitude expansion factor, altitudes are 

raised to this power to give an 
exagerrated effect */ 



NUMXGRIDS 


10 


/* number of IK grid squares in 


the East- 




West direction */ 




NUMZGRIDS 


10 


/* number of Ik grid squares in 


the North- 




South direction */ 




FTIOK 


32808 


!* number FT in lOKm 


V 


FTIOOM 


328.08 


/* number FT in 100m 


*/ 


GRID FACTOR 


13.03781 /* conversion factor 




TV 0 


/* 


0 for SGI monitor, 1 for TV 


V 


SCREENDUMP 1 


/* 1 to enable screen dumping, 0 otherwise 


NETWORKING 0 


/* 1 for target networking, 0 otherwise * 


INIT PAN 


0 


/* initial, min and max pan angles 


in deg. */ 


MIN PAN 


-25 






MAXPAN 


25 






INIT TILT 


-15 


/* initial, min and max tilt angles 


in deg.*/ 


MIN TILT 


-25 






MAXTILT 


15 






MAX ALT 


17000 


/* maximum altitude for missle 


V 


MINALT 


0 


/* minimum altitude for missle 


V 


INIT SPEED 


200 


/* init, min and max spd (kts) 


for missle */ 


MIN SPEED 


0 






MAX SPEED 


400 






INITFOVY 


550 


/* initial field of view in tenth degrees */ 
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^define 


CONTOUR 




0 /* Indicies for arra 


^define 


SCREENl 


1 




^define 


SCREEN2 


2 




^define 


SCREENS 


3 




^define 


INSTR 


4 




#define 


STATS 


5 




^define 


FLTPATH 




6 


^define 


LAUNCH 


0 


/* Indicies for array tag 


=^define 


TARGET 


1 




^define 


DIR 


2 




^define 


HEAD 


3 




^define 

#^define 


TGT 4 

MISSILE 


5 





#define MAX TGT COLOR 847 
#define MIN TGT COLOR 668 



^define 


MAXTGTS 


100 


^define 


SAVEMAP 


OxOOCO 
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GAMMARAMP 



/* This routine puts a gamma-corrected color ramp into the color map. */ 
^include <math.h> 

gammaramp(gammaconst,firstcolor,ncolors, 

brightred,brightgreen,brightblue, 

darkred,darkgreen,darkblue) 

float gammaconst; /* Strength of Gamma correction (try 1.0) */ 
long firstcolor; /* index number of the first color to set */ 
long ncolors; /* the number of colors to set */ 

long brightred,brightgreen,brightblue; /* the bright end of the ramp */ 
long darkred,darkgreen,darkblue; /* the dark end of the ramp */ 

{ 

long i; /* temp loop index */ 

float scl; /* scale factor for gamma correction */ 

long gcred,gcgreen,gcblue; /* gamma corrected colors */ 

for( i=0; i < ncolors; 1 + + ) /* for all colors...*/ 

{ 

/* compute the scale factor */ 

scl = pow((float)i/(float) (ncolors-l) , 1.0/gammaconst); 

/* compute the gamma corrected colors */ 
gcred = scl * (brightred - darkred) -h darkred; 
gcgreen = scl * (brightgreen - darkgreen) + darkgreen; 
gcblue — scl * (brightblue - darkblue) -h darkblue; 

mapcolor(firstcolor-t-i, gcred, gcgreen, gcblue); /* set the color */ 

} 

} 
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GET TGT POS 



/* get targets’ positions from irisl if networking. Otherwise moves 10 targets 
in straight lines, reversing when they hit an edge */ 

#include ”fogm.h’* 

^include ”gl.h” 

^include ’’math.h" 

^include <sys/types.h> /* contains the time sturcture tms */ 

^include <sys/times.h> /* for time calls */ 

get tgt posit (socket, designate, tgt_idx,tgtx,tgty,tgtz, tank) 

int socket, designate, tgt idx; 
float *tgtx, *tgty, *tgtz; 

Object tank; 

{ 

extern float tgt pos[MAX TGTS][3]; 

extern float randx, randy, randz; 

extern Object target[99][99]; 

extern short tgt_grid_idx[MAX_TGTS][2]; 

extern short tgt_total, tgt_dir[MAX_TGTS]; 

short i, tgt num; 

int nbyte, addl(); 

float gnd level(), dir, dx, dz, distance; 
long dist, d2; 
static long seconds; 

static long lastsec = -999; /* -999 is flag to indicate no value */ 

struct tms timestruct; 

seconds = times(&timestruct); 

if (lastsec == -999) /* compute distance targets move ahead */ 

distance = 0.0; 

else 

distance = (float) ((15. 0/FPS_TO KTS) * (seconds - lastsec)); 
lastsec = seconds; /* save for next pass */ 

for (i = 0; i < tgt total; i+-h) /* delete targets from old positions */ 

if (target[tgt_grid_idx|i]10])|tgt_grid_idx[i][l]]) { 

delobj(targetltgt_grid_idx[i][0]][tgt_grid_idx[i][l]]); 
target|tgt_grid_idx[i][0^1][tgt_grid_idx[i][T)] = 0; 

} 

if (NETWORKING) { 

nbyte = read(socket, &tgt total, sizeof(tgt total)); 
for (i = 0; i < tgt total; i+ + ) { 

nbyte = read (socket, <&!tgt grid idx[i][0], sizeof(short)); 
nbyte = read(socket, &tgt_grid_idx[i][l], sizeof(short)); 
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nbyte = read(socket, <^:tgt_pos[i][Oj, sizeof(float)) ; 
nbyte = read(socket, &:tgt_pos[i][l], sizeof(float)); 
nbyte = read(socket, &:tgt_pos[i][2], sizeof(float)); 
nbyte = read(socket, &tgt_dir[i], sizeof(short)); 

} 

} 

else { 

tgt_total = 10; 

for (i — 0; i < tgt_total; i+H-) { 

dir = (float)(tgt_dir[ij / 10) * DTOR; 
tgt_pos[i][0] += cos(dir) * distance; 
tgt pos[i][2] -= sin(dir) * distance; 
tgt_grid_idx[i][0] = (short) (tgt_pos[i][0]/FT_100M); 
tgt grid idx[i][l] = (short) (-tgt pos[i][2]/FT_100M); 
if ((tgt_pos[i][0] > FT_10K) || (tgt_pos[i][0] < 0)) { 
if (tgt dir[i] > 1800) tgt dir[i] -= 1800; 
else tgt dir i] += 1800; 
tgt_pos[i][l j = 0.0; 

} 

else if ((tgt_pos[i][2] < -FT_10K) || (tgt_pos[i][2] > 0)) { 
if (tgt_dir[i] > 1800) tgt_dir[i] -= 1800; 
else tgt_dir:i] += 1800; 
tgt_pos[i][ 1 j = 0.0; 

} 

else tgt_pos[i][l] = gnd_level(tgt_pos[i][0], tgt_pos[i][2]); 

} _ 

} 

if (Idesignate) { 

if (NETWORKING) { /* find which target is designated */ 

dist = up i((float)(tgt pos[0][0] - *tgtx),2) -h 
up_i((float)(tgt_pos[0][2] - *tgtz),2); 
tgt idx = 0; 

for (i = 1; i < tgt total; i-h-h) { 

d2 = up_i((float)(tgt pos[i][0] - *tgtx),2) + 
up_i((float)(tgt_pos[i][2l - *tgtz),2); 
if (d2 < dist) { 
dist = d2; 
tgt_idx = (int)i; 

} 

} 

} 

*tgtx = tgt_pos[tgt_idx][0] + randx; 

"^tgty = tgt_pos[tgt_idx][l] + randy; 

*tgtz = tgt_pos[tgt_idx][2] + randz; 

} 

tgt num — tgt total; 

for (i = 0; i < tgt num; i+ + ) { 

dx = tgt_pos[i][0j - (float)tgt_grid_idx[i][0] * FT lOOM; 
dz = (float)(-tgt_grid_idx[i][l]) * FT_100M - tgt_pos[i][2]; 
if (dx < 15.0) 

if (dz < 15.0) { 
addl(i,-l,0); 
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addl(i,0,-l); 

} 

else if (dz > 313.0) { 
addl(i,0,l); 
addl(i,-l,l); 
addl(i,-l,0); 

} 

else addl(i,-l,0); 

else if (dx > 313.0) 
if (dz < 15.0) { 

addl(i,0,-l); 

addl(i,l,-l); 

addl(i,l,0); 

} 

else Lf (dz > 313.0) { 
addl(i,l,0); 

addl(i,l,l); 

addl(i,0,l); 

} 

else addl(i,l,0); 

else if (dz < 15.0) addl(i,0,-l); 

else if (dz > 313.0) addl(i,0,l); 

} 

for (i = 0; i < tgt total; i+ + ) /* add targets to new positions * j 

if (target[tgt_gridjdx[ij[0]][tgt_grid jdx[ij[l]l) { 

editobj( target [tgt_grid_idx[i][0]][tgt_grid_idx[i][l]]); 
pushmatrix(); 

translate(tgt pos[i|[0],tgt pos[i][l|,tgt pos|i][2]); 

rotate(tgt dir[i], ’Y’); 

callobj(tank); 

popmatrix(); 

closeobjO; 

} 

else { 

target|tgt grid idx[i|[0]][tgt grid idxji^’lj] = genobj(); 
makeobj (target I tgt grid idx[i][0]j[tgt_grid_idx[i][l]]); 
pushmatrix(); 

translate(tgt pos[i][0],tgt pos[i][l],tgt pos[i][2]); 

rotate(tgt dir[i], ’Y’); 

callobj(tank); 

popmatrix(); 

closeobjO; 

} 

} 



addl(tgt_num,x,z) 

short tgt^num,x,z; 

{ 

extern float tgt pos[MAX_TGTS][3]; 
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extern short tgt_^grid_idx[MAX_TGTS][2j; 
extern short tgt_total, tgt_dir[MAX_TGTSj; 
short i; 

tgt pos[tgt total][0| = tgt pos[tgt num]|0]; /* copy pos. for “new” tgt */ 

tgt_pos[tgt_total][l] = tgt_pos[tgt_num][l]; 
tgt pos[tgt_total][2| = tgt_pos[tgt__num]|2]; 

tgt dir[tgt_total] = tgt_dir[tgt num]; /* copy dir for “new” tgt */ 
tgt_grid_idx[tgt_total][0] = tgt_grid_idx[tgt_num][0) -h x; /* set pos in * / 
tgt grid_idx[tgt_total][l] = tgt_grid_idx[tgt_num][l) + z; /* new grid sq */ 
for (i = 0; i < 2; i++) { /* reset if new grid sq outside 10km square */ 

if (tgt grid idx[tgt totaljji] < 0) tgt grid_idx[tgt^total|[i] = 0; 
if (tgt_grid_idx[tgt_totalj[ij > 98) tgt_grid_idx[tgt_total][i] = 98; 

} 

tgt total 
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GND LEVEL 



^include "math.h'* 
^include "fogm.h" 
^define X 0 
#define Y 1 
#define Z 2 
float gnd_level(vx, vz) 

float vx, vz; 



extern short gridpixelj 100][l00]; 
float interp_elev(); 
float grid level(); 

float point 3], nw_corner[3], ne_cornerj3] , sw_corner[3|, se corner[3]; 
float intersect[3]; 
float elev; 

int xgrid, zgrid, intersect_type; 

/* determine which triangle the point falls in */ 

xgrid = (int)(vx/FT lOOM); 

zgrid = (int)(-vz/FT lOOM); 

if (xgrid < 0) xgrid = 0; 

if (xgrid > 98) xgrid — 98; 

if (zgrid < 0) zgrid = 0; 

if (zgrid > 98) zgrid = 98; 

point|X] = vx; 

point|Z) = -vz; 

nw_corner X] = (float)(xgrid*FT lOOM); 
nw corner Z] = (float)((zgrid - 4 - l)*FT_100M); 
elev = gridpixel[zgrid+l][xgrid] &; elev mask; 
nw corner Y] = pow(elev, ALTSCALE); 
sw corner|X] = (float) (xgrid* FT lOOM); 
sw corner|Z] = (float)(zgrid*FT lOOM); 
elev = gridpixel[zgrid| [xgrid] &: elev mask; 
sw corner|Y] = pow(elev, ALTSCALE); 
ne_corner[X| = (float)((xgrid+l)*FT lOOM); 
ne cornerjZj = (float)((zgrid-rl)*FT_100M); 
elev = gridpLxel[zgrid+l]|xgrid-H l] &; elev mask; 
ne corner|Y| = pow(elev, ALTSCALE); 
se cornerjXj = (float)((xgrid-h 1)*FT_100M); 
se^corner[Z| = (float)(zgrid*FT lOOM); 
elev = gridpixeljzgridj [xgrid + ij &; elev mask; 
se corner[Y| = pow(elev, ALTSCALE); 

if (-VZ < (nw_corner[Z] - (vx - nw_corner[X]))) { 
point is in the lower triangle */ 

/* find the point of intersection of a line through vx,vz 
and the sw corner with the diagonal */ 
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line intersect2(sw corner, point, nw corner, se corner, intersect, 
(^intersect type); 

/* find the elevation of the intersection on the diagonal * / 
intersect [Y] = interp elev(nw corner, se corner, intersect); 

/* find the elevation of the point vx, vy */ 
return(interp elev(sw corner, intersect, point)); 

} 

else { 

/* point is in the upper triangle * / 

/* find the point of intersection of the diagonal with a line 
through th ne corner and the point * / 
line intersect2(ne corner, point, nw corner, se corner, intersect, 
intersect type) ; 

/* find the elevation of the intersection on the diagonal */ 
intersectjY] = interp elev(nw corner, se corner, intersect); 

/* find the elevation of the point vx, vz */ 
return(interp elev(ne corner, intersect, point)); 

} 

} 
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IN THIS POLY 



^include ”gl.h" 

^define X 0 

^define Y 1 

#define Z 2 

#define PROPER 2 



int in_this_poly(polygon, num_vertex, point) 
float polygon[l0)[3]; 
int num vertex; 
float point[3]; 

{ 

int index; 

int pt in, intersect_type; 

int num_crossings; 

float max_x, max_z, min_x, min_z; 

float intersect j3]; 

float old intersect[3); 

float start test line[3]; 

max_x = polygon 0][Xj; 
min_x = polygon[0j(X]; 
max z = polygon[0;[Zj; 
min z = polygonjOljZj; 

for (index = 1; index < num vertex; 4- + index) { 

if (polygon[index][X] < min x) min x = polygon|index][Xj; 
if (polygon[index][X] > max x) max x = polygon [index] [X]; 
if (polygon|index][Z| < min z) min z = polygon[index]|Z|; 
if (polygon[indexj[Z| > max z) max z = polvgon[index|[Zj; 

} 

if ((point[X| < max_x) (pointjXj > min_x) (pointjZj < max^z) 

(point|Zj > min_z)) { 

j* point may be polygon, test further by constructing a vertical line 

from the point to a point outside the polygons bounds. Count the number 
of times this line crosses a side of the polygon. If it crosses an 
odd number of times the point is in the polygon, otherwise it is 
outside the polygon */ 

start test linejXj = pointjXj; 
start test_line[Z] = max_z -h 1000.0; 

num_crossings = 0; 
old_intersect[X] = -999.0; 
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old_intersect[Z] = -999.0; 

for (index = 0; index < num vertex -1; +^index) { 

line intersect2(start^test line, point, &polygon[index][0], 
&:polygon[index+li[0], intersect, &intersect_type); 

I* if a proper intersection exists and it is not the same point 

as the previous intersection (i.e it didn’t intersect a vertex), 
then add one to the number of crossings */ 
if ((intersect type == PROPER) &;&; ((intersect[X] != old intersect[X|) 
II (intersectjZ] != old_intersect[Z]))) num_crossings ->r= 1; 
old intersectjX] = intersectjX]; 
old_intersect[Z] = intersect[Z]; 

} “ 

line intersect 2 (start test line, point, &;polygon[num_vertex-lJ[0], 
&polygon[0][0], intersect, &:intersect type); 
if (intersect type == PROPER) num crossings += 1; 

/* if the number of crossings is even, the point was outside * / 
pt in = ((num crossings % 2) != 0); 
return(pt in); 

} 

else { 

return(FALSE); 

} 

} 
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INIT CTRLS 



/* initialize the operator controls */ 



^include "fogm.h" 
:j5^include ’’device. h’* 
^include ”gl.h" 
^include ’’math.h” 



/* fogm constants */ 

/* graphics device definitions */ 
/* graphics routine definitions */ 
/* math function definitions */ 



init controls(pan, tilt, fovy, alt, greyscale, compassdir) 



double *pan; 
double *tilt; 
int *fovy; 

Coord alt; 
int greyscale; 
float compassdir; 



/* initial pan angle in radians * / 

/* initial tilt angle in radians */ 

/* initial field of view in tenths of degrees */ 
/* initial altitude of missile */ 

/* initial value of greyscale boolean */ 

/* initial compass direction */ 



{ 



*pan = INIT PAN * DTOR; 

*tilt = INIT TILT * DTOR; 

*fovy = INIT_FOVY; 

/* set initial, min, and max values for mouse & dials */ 

setvaluator(MOUSEX,(short)(lNIT_PAN*PANSENS),(short)(MIN_PAN*PANSEi\S), 

(short)(MAX_PAN*PANSENS)); 

setvaluator(MOUSEY,(short)(INIT_TILT*TILTSENS),(short)(MIN_TlLT*TILTSENS), 

(short)(MAX_TILT*TlLTSENS)); 

setvaluator(DIALO,(short)(compassdir*DIRSENS), (short ) (-360* DIRS ENS), 
(short)(720*DIRSENS)); 

setvaluator(DIAL4,(short)alt,MIN ALT, MAX ALT); 

setvaluator(DIAL2, (short)(INIT_SPEED*SPEEDSENS), 
(short)(MIN_SPEED*SPEEDSENS), 

(short)(MAX_SPEED*SPEEDSENS)); 



} 



setvaluator(DIAL3,greyscale,0,l); 
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INIT IRIS 



/* Initialize the graphics environment for the iris workstation */ 



^include "gl.h" 
#include ”get.h” 
^include "fogm.h” 



/* graphics definitions */ 

/* monitor type definitions */ 
/* fogm constants */ 



init iris() 

{ 



long chunk; 



ginit(); 

doublebuffer(); 
chunk = 128 ; 
chunksize(chunk); 
gconfigO; 
if (TV) { 

setmonitor(NTSC); 
fontdef(l,"TV.font”); 
font(l); 

} 

else setmonitor(HZ 60 ); 

cursoff(); /* turn off the cursor 



/* number of bytes be which objects 
increment */ 

/* initialize the IRIS system */ 

/* put the IRIS into double buffer mode */ 



/* (means use the above command settings) */ 

/* choose tv or SGI monitor */ 



7 



backface(TRUE); 



/* turn on backface polygon removal 



color(BLACK); 

clear(); 

swapbuffers(); 
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INIT TGTS 



^include '’fogm.h'* 

^include ”gl.h” 

init tgts() 

{ 

extern short tgt total; 
extern Object target [99] [99]; 
short X, y; 
int init tgt(); 

for (x = 0; X < 99; x+-f-) for (y = 0; y < 99; y + + ) target[x|[y] = 0; 
if (IxNETWORKING) { 
tgttotal = 10; 
init tgt(0,9.8,3.5,1295); 
init_tgt( 1,9.5,3.5,1295); 
init tgt(2,9.4,3.1,1295); 
init tgt(3,9.8,0.5,1800); 
init tgt (4, 9. 5, 0.0, 1355); 
init_tgt(5,8.0,0.0,1445); 
init_tgt (6,4.0,0.0,1450); 
init tgt(7,0.0,0.5,450); 
init tgt(8,9.5,9.8,2700); 
init tgt(9,9.8,8.5,1800); 

} 

} 

init tgt(tgt num,xoffset,zoffset, direction) 

short tgt num, direction; 
float xoffset, zoffset; 

{ 

extern short tgt dir[MAX TGTS]; 
extern float tgt pos[MAX TGTS]|3]; 

tgt_pos[tgt num][0] = xoffset * FEETPERGRID; 
tgt_pos[tgt_num][2] = -zoffset * FEETPERGRID; 
tgt dir[tgt_num] = direction; 

} 
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INTERP ELEV 



^include ’^math.h" 

#define X 0 

fdefine Y 1 

fdefine Z 2 

float interp elev(line start, line end, point) 

float line start[3], line end[3], point[3]; 

long float line deltax, line deltaz, point deltax, point deltaz; 
float line length, dist^to point; 
float interpolation; 

line deltax = (long float)(line endjX] - line_start[X)); 
line deltaz = (long float)(line end[Z] - line_start[Z]); 

point deltax = (long float) (line start [X] - point[X]); 
point deltaz = (long float)(line start[Z] - pointjZ]); 

line^length = (float)hypot(line deltax, line deltaz); 
dist to point = (float)hypot(point_deltax, point deltaz); 

interpolation = line start[Y] ^ ((line end[Y] - line startjY]) * 
(dist to_point/line_length)); 

return (interpolation) ; 

} 
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LIGHTORIENT 



/* this is file lightorient.c */ 

r 



It is a routine that computes lighting for a polygon based 
upon the angle between the Normal vector of the polygon 
and the direction to the light source. 

lightorient(xyz,ncoords,ax,ay,az,lx,ly,lz,colormin,colormax,colortouse) 
xyz[][3] = floating coords of the polygon, 
ncoords = number of coordinates. 

ax,ay,az = interior point of the whole object. Used to determine 
outward facing normal of the polygon. This is the same 
point of reference that would be used for backface 
polygon removal. 

lx,ly,lz = vector pointing in direction of the light source. 

colormin, colormax = indices used for the colors assigned to this 
polygon. The user is responsible for setting 
up the color ramp. 

colortouse = returned color used to light the polygon. 

Note: the routine also puts the polygons out ordered counterclockwise 
with respect to the interior point for ease of backface polygon 
removal. 



*! 

^include <math.h> 

^include <gl.h> 

#define MAXCOORDS 80 
#define PIDIV2 1.570796327 

float txyz[MAXCOORDSj[3]; /* temp coord hold */ 



lig htorien t (xyz, ncoords, ax, ay, az,lx,ly,lz,colormin, colormax, colortouse) 

float xyz[][3]; 
long ncoords; 
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float ax,ay,az; /* interior point of the whole object. */ 

float lx,ly,lz; /* direction to the light source */ 

long colormin,colormax; /* color min/max indices */ 

long *colortouse; /* color used to light the polygon (return value) */ 



long i,j; /* loop temps */ 

long npoly orient(); /* direction test function */ 



float vl[3],v2[3]; 

float normal[3]; 
float normalmag; 
float lightmag; 
double dotprod; 
float radians; 



/* vectors used to compute 
the polygon’s normal */ 

/* the polygon’s normal */ 

/* normal’s magnitude */ 

/* magnitude of the light vector */ 

/* dot product of N and L */ 

/* angle between N and L */ 



/* check the number of coords in the input array */ 
if(ncoords > MAXCOORDS) 

{ 

printf(”LIGHTORIENT: too many coords passed to me! = %dO,ncoords) 
exit(l); 

} 

/* orient the polygon so that its counterclockwise with respect 
to the interior point */ 

if(npoly orient(ncoords,xyz,ax,ay,az) == 1) 

/* the polygon is clockwise, reverse it. */ 
for(i=0; i < ncoords; i=i+l) 

{ 

for(j=0; j < 3; j=j+l) 

{ 

txyz[i][j| = xyz|ncoords-i-l]|j|; 

} 

} 

for(i=0; i < ncoords; ++i) 
for (j=0; j < 3; ++j) 

xyzli](j| = txyz(i][j|; 
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} 



/* the coordinates are ordered counterclockwise in array xyz */ 

/* compute the normal vector for the polygon using the first 
three vertices...*/ 

/* compute the first vector to use in the computation */ 
vliO) = xyz[2][0] - xyz|l][0]; 
vl|l] = xyz(2][l] - xyz[l](l]; 
vll2] ^ xyz(2)[2] - xyz(lii2]; 

/* compute the second vector to use in computing the normal */ 
v2i0’ = xyz[0](0] - xyz[l](0]; 
v2^1j = xyziojjl] - xyz|l](l]; 
v2[2 = xyz[0)(2] - xyz[l][2]; 

/* the normal is vl x v2 */ 
normal[0] = vl[l]*v2[2] - vl(2]*v2[l|; 
normai;i] = vl[2]*v2[0] - vl[0l*v2l2]; 
normal[2] = vl[0]*v2|l] - vl[l]*v2(0]; 

/* compute the magnitude of the normal */ 

normalmag sqrt((normal[0 *normal[Ol)-f-(normal[l]*normal[l])H- 
(normal[2]*normal(2])); 

/* check the magnitude of the normal */ 
if(normalmag == 0.0) 

{ 

normalmag = 0.00001; /* a small number */ 

} 

/* compute the light mag */ 

lightmag = sqrt((lx*lx)-|-(ly*ly)^(lz*lz)); 

if(lightmag == 0.0) 

{ 

lightmag = 0.00001; /* a small number */ 

} 



/* compute N . L (normal dot product with the light source direction) */ 
dotprod = (normaljO] * lx) -f (normaljl] * ly) -f (normal[2j * Iz); 

dotprod = dotprod/(lightmag*normalmag); 

/* dotprod = cos(theta) of the angle between N and L. 

Convert to angle in radians */ 
radians = acos(dotprod); 

/* compute the color we should use */ 
if(-PIDIV2 <= radians radians <= PIDIV2) 

{ 
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I* if the angle is negative, set to positive */ 
if(radians < 0.0) 

{ 

radians = -radians; 

} 



*colortouse = ((colormax-colormin) /PIDIV2)*(PIDIV2-radians)+colormin; 

} 

else 

{ 

*colortouse = colormin; 

} 

/* set the color */ 
color(*colortouse); 

/* draw the poly */ 

/* polf(ncoords,txyz); */ 



} 
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LINE INTERSECT2 



^include "gl.h'' 

#define X 0 
^define Z 2 
^define NONE 0 
#define INTERSECT 1 
#define PROPER 2 



line intersect2(startl, endl, start2, end2, intersect, 
intersect type) 

float startl[3], endl[3], start2[3], end2[3j, intersect|3]; 
int *intersect_type; 



{ 

/* given two lines of the form z = mx + b and z = nx + c, 
solving for x when the z’s are equal gives x = (c-b)/(m-n). 

Then solve for z using x in either of the above equations. */ 

float m,n,b,c; 

float mini x, min2_x, maxl_x, max2_x, minl_z, min2_z, maxi z, max2 z; 

^intersect type = PROPER; 

/* slope and z intercept of linel */ 
if (endl|X] != startl[X ) { 

m = (endl[Z - startl[Z|)/(endl|X; - startl X|); 

b = ((startl Z] - endl[Z])/ (endl[X) - startl X])) * startljX] -h startl|Z] 
if (end2|X] != start2[X]) { /* both lines are non-vertical */ 

/* slope and z intercept of line2 */ 
n = (end2 Z] - start2[Z))/(end2|X| - start2^Xj); 
c = ((start2[Z - end2[Zj)/ (end2|X’ - start2.X])) * start2[XJ -h 
start2 Z|; 

if (m !— n) { 

intersect[X) = (c-b)/(m-n); 
intersect[Zj = m*intersect[X] + b; 

} 

else { /* both lines have equal slopes * / 

* intersect type = NOxNE; 

} 

} 

else { /* linel is non-vertical, line2 is vertical * / 
intersectjX) = end2|X]; 
intersectjZ] = m*intersect[X] -t- b; 

} 

} 

else { 



184 



if (end2[Xj != start2[X]) { /* linel is vertical, line2 is non-vertical*/ 
/* slope and z intercept of line2 * / 
n = (end2jZj - start2jZ])/(end2[X] - start2[X]); 
c = ((start2[Zj - end2[Z])/(end2[X] - start2[X])) * start2[X] + 
start2lZ); 

intersect[X] = endl[X]; 
intersect|Z] = n*intersect[X] -j- c; 

} 

else { /* both lines are vertical */ 

*intersect_type = NONE; 

} 

} 

if (* intersect type != NONE) { 

/* see if the intersection is proper, or if only the extensions of the 
line segments intersect */ 
if (startl|X] < endl[X]) { 
minl_x = startljX]; 
maxlx = endl|X]; 

} 

else { 

mini X = endl[X]; 
maxi X = startljX]; 

} 

if (startljZ] < endljZ]) { 
mini z = startljZj; 
maxi z = endljZj; 

} 

else { 

minlz = endljZj; 
maxl z = startl Zj; 

} 

if (start2|X| < end2[X]) { 
min2_x = start2[X|; 
max2 X = end2[Xj; 

} 

else { 

min2_x = end2[Xj; 
max2_x = start2[X|; 

} 

if (start2[Z| < end2[Zj) { 
min2_z = start2[Zj; 
max2_z = end2[Z]; 

} 

else { 

min2_z = end2|Z|; 
max2^z = start2|Zj; 

} 
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if ((intersectjX] <= maxl_x) &:&: (intersect[X] <= max2 x) && 
(intersect[X] >= minl_x) (intersect[X] >= min2 x) 
(intersect[Z] <= maxl^z) && (intersect[Z] <= max2 z) 
(intersect[Z] >= mini z) (intersectjZ] >= min2 z)) { 

*intersect_type = PROPER; 

} 

else { 

*intersect_type = INTERSECT; 

} 

} 

} 
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MAKENAVBOX 



/* drawnavbox.c - this function is called by the FOG-M missile simulator to 
build an object on top of the contour map in the upper right-hand corner 
of the screen. Navbox contains the direction arrow and view box in red. */ 

^include "gl.h" 

^include ’’fogm.h” 

^include "device. h” 

drawnavbox(navbox, arrowtag) 

Object *navbox; 

Tag *arrowtag; 

{ 

*navbox = genobj(); /* create the navigation contol and display object */ 

makeobj(*navbox); 

if (TV) viewport(475,635,323,474); 

else viewport(768, 1023, 512, 767); /* upper right hand corner of screen */ 
pushmatrix(); /* draw arrow in feet coordinates */ 

ortho2(-10.0,10.0 + NUMXGRIDS*FEETPERGRID, -10.0, 

-10.0 - NUMZGRIDS*FEETPERGRID); 

color(BLACK); 

clear(); 

color( 128); 

*arrowtag = gentag(); 
maketag(* arrowtag); 
move2(0. 0,0.0); 
draw2(0. 0,0.0); 
draw2(0. 0,0.0); 
move2(0. 0,0.0); 
draw2(0.0, 0.0); 

rect(0. 0,0. 0,0. 0,0.0); /* view box */ 

popmatrix(); 

closeobjO; 

} 
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MAKEINDBOX 



/ 



makeindbox.c is a function that creates an object that displays the control 
idicators for the FOG-M missile simulation */ 



^include "gl.h” 
^include "fogm.h" 



makeindbox(indbox,headingtag,elevtag,altmsltag,speedtag,zoomtag,tilttag,pantag,desigtag) 
Object *indbox; 

Tag *headingtag, *elevtag, *speedtag, *zoomtag, *tilttag, *pantag, *desigtag; 

Tag *altmsltag; 

{ 

*indbox = genobj(); 

makeobj(*indbox); 

if (TV) viewport(475,635,162,322); 

else viewport(768, 1023, 256, 511); /* middle box on side of screen * / 

pushmatrix(); 

ortho2(0. 0,255. 0,0. 0,255.0); /* use screen sized coordinates */ 

color(854); /* clear the window * / 

clear(); 

linewidth(2); 



color(BLACK); 

recti(0, 0,255, 255); /* outline box */ 



color( YELLOW); /* print labels for readouts */ 

cmov2i(l0,240); 

charstr(”SPEED”); 

cmov2i(55,225); 

charstr("kts”); 

cmov2i(90,240); 

charstr(”HEADING"); 

circ(140. 0,232. 0,3.0); /* "degree" symbol * / 

cmov2i(l80,240); 

charstr("Alt AGL"); /* AGL = above ground level * / 

cmov2i(225,225); 

charstr("ft"); 

cmov2i( 180,200); 

charstr("Alt MSL"); MSL = mean sea level * / 

cmov2i(225,185); 

charstr("ft"); 



cmov2i(50,130); 

charstr("ZOOM"); 

move2i(45,200); 

draw2i(25,200); 

draw2i(25,70); 

draw2i(45,70); 

cmov2i(15,196); 



j* draw slider bar frame * / 
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charstr("8"); /* label slider bar values */ 

cmov2i(6,170); 

charstr(”15”); 

cmov2i(6,144); 

charstr("25”); 

cmov2i(6,118); 

charstr("35"); 

cmov2i(6,92); 

charstr(”45”); 

cmov2i(6,66); 

charstr("55"); 



color(WHITE); 
cmov2i(l0,225); 
*speedtag = gentag(); 
maketag(*speedtag); 


/* readouts in white... ^ / 

/* initialize to dummy values */ 



charstr(" 200"); /* speed */ 

cmov2i(108,225); 

*headingtag = gentag(); 

maketag(*headingtag); 

charstr(" 0"); /* heading * / 

cmov2i(l80,225); 

*elevtag = gentag(); 



maketag(*elevtag); 

charstr("1000"); 


/* altitude above ground level */ 


cmov2i(l80,185); 
*altmsltag = gentag(); 
maketag(*altmsltag); 
charstr("1000"); 

color(RED); 


/* altitude from mean sea level */ 


*zoomtag— gentagO; 
maketag(* zoom tag); 
move2(28. 0,135.0); 
rdr2(10.0,5.0); 
rdr2(0.0,-10.0); 
rdr2(-10.0,5.0); 

popmatrix(); 


/* indicator for zoom slider bar */ 



if (TV) viewport(0, 474, 0,474); /* reset for heads-up display */ 

else viewport(0, 767, 0,767); 

pushmatrix(); 

ortho2(0. 0,767. 0,0. 0,767.0); /* use screen sized coordinates */ 

color(WHITE); 
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if (TV) linewidth(2); 
else linewidth(l); 

rectfi(365,370,370,375); /* draw center of crosshairs * / 

reel fi(396,370,401,375); 

rectfi(365,391,370,396); 

rectfi(396,391,401,396); 

move2i(0,383); 

draw2i(360,383); /* draw crosshairs * / 

move2i(406,383); 

draw2i(767,383); 

move2i(383,0); 

draw2i(383,365); 

move2i(383,40l); 

draw2i(383,767); 

linewidth(2); 

move2i(30,50); /* draw TILT slider bar frame */ 

draw2i(40,50); 

draw2i(40,680); 

draw2i(30,680); 

cmov2i(0,676); 

charstr(*' + 25”); /* label slider bar values * / 

cmov2i(0,613); 

charstr(" + 20"); 

move2i(30,617); 

draw2i(40,617); 

cmov2i(0,550); 

charstr(" + 15"); 

move2i(30,554); 

draw2i(40,554); 

cmov2i(0,487); 

charstr("^ 10"); 

move2i(30,49l); 

draw2i(40,49l); 

cmov2i(0,424); 

charstr(” +5"); 

move2i(30,428); 

draw2i(40,428); 

cmov2i(0,36l); 

charstr(" 0"); 

move2i(30,365); 

draw2i(40,365); 

cmov2i(0,298); 

charstr(" -5"); 

move2i(30,302); 

draw2i(40,302); 

cmov2i(0,235); 

charstr("-lO"); 

move2i(30,239); 

draw2i(40,239); 
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cmov2i(0,172); 

charstr(”-15”); 

move2i(30,176); 

draw2i(40,176); 

cmov2i(0,109); 

charstr("-20'’); 

move2i(30,113); 

draw2i(40, 113); 

cmov2i(0,46); 

charstr(*’-25”); 

*tilttag = gentagO; /* indicator for TILT slider bar * / 

maketag(*tilttag); 

move2(42. 0,365.0); 

rdr2(l0.0,-5.0); 

rdr2( 0.0,10.0); 

rdr2(-8.0,-4.0); 

rdr2( 6.0, -3.0); 

rdr2( 0.0, 4.0); 

rdr2(-2.0,-1.0); 

rdr2( 1.0,-1.0); 

move2i(l20,15); /* draw PAN slider bar frame */ 

draw2i(l20,25); 

draw2i(750,25); 

draw2i(750,15); 

cmov2i(l07,3); 

charstr('’-25"); /* label slider bar values */ 

cmov2i(l70,3); 

charstr(”-20*’); 

move2i(183,15); 

draw2i(183,25); 

cmov2i(233,3); 

charstr(”-15“); 

move2i(246,15); 

draw2i(246,25); 

cmov2i(296,3); 

charstr(”-10*‘); 

move2i(309,15); 

draw2i(309,25); 

cmov2i(363,3); 

charstr(”-5”); 

move2i(372,15); 

draw2i(372,25); 

cmov2i(431,3); 

charstr(”0"); 

move2i(435,15); 

draw2i(435,25); 

cmov2i(494,3); 

charstr(”-h5*’); 

move2i(498,15); 

draw2i(498,25); 
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crnov2i(552,3); 

charstr("^ 10’*); 

move2i(561,15); 

draw2i(561,25); 

cmov2i(615,3); 

charstr(” + 15”); 

move2i(624,15); 

draw2i(624,25); 

cmov2i(678,3); 

charstr(” + 20”); 

niove2i(687,15); 

draw2i(687,25); 

cmov2i(741,3); 

charstr(” + 25”); 

*pantag = gentag(); /* indicator for PAN slider bar */ 

maketag(*pantag); 

move2(435. 0,27.0); 

rdr2( 5.0,10.0); 

rdr2(-10.0, 0.0); 

rdr2( 4.0,-8.0); 

rdr2( 3.0, 6.0); 

rdr2( -4.0, 0.0); 

rdr2( 1.0, -2.0); 

rdr2( 1.0, 1.0); 

move2i(0,30); designate/reject box * / 

draw2i( 100,30); 
draw2i( 100,0); 

*desigtag = gentag(); 
maketag(*desigtag); 
cmov2i( 10,10); 
charstr("DESIGNATE”); 

popmatrix(); 

closeobjO; 
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MAKEINSTRBOX 



/* makeinstrbox.c - this function builds an object that contains an instruction 
summary for the FOG-M missile simulation * j 

^include "gl.h’* 

^include "fogm.h” 



makeinstrbox(instrbox) 
Object *instrbox; 



*instrbox = genobj(); 

makeobj(*instrbox); 

if (TV) viewport(475, 635, 0,161); 

else viewport(768, 1023,0,255); /* box is in lower right hand corner */ 

pushmatrix(); 

ortho2(0. 0,255. 0,0. 0,255.0); /* use screen-sized coordinates * / 

color(851); /* use a medium green */ 

clear(); 

linewidth(2); 



color(852); 

rectfi(l0,20,110,195); 

rectfi(l35, 80,245, 195); 

color(BLACK); 

recti(10,20,110,195); 

recti(135,80,245,195); 

recti(0, 0,255, 255); 



/* use light brown */ 

/* draw the mouse control box */ 
/* draw the dial control box */ 
/* outline controls */ 



color(BL ACK); 

cmov2i(60,230); 

charstr(”C O N T R O L S"); 

cmov2i(37,200); 

charstr( ’’MOUSE”); 

cmov2i( 172,200); 

charstr( ’’DIALS”); 

cmov2i(25,60); 

charstr(”TILT”); 

move2i(70,62); /* draw arrow */ 

draw2i(75,55); 

draw2i(75,75); 

draw2i(70,68); 

move2i(75,75); 

draw2i(80,68); 

move2i(75,55); 

draw2i(80,62); 
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cmov2i(25,30); 
charstr(”PAN”); 
move2i(67,40); 
draw2i(60,35); 
draw2i(80,35); 
draw2i(73,40); 
move2i(80,35); 
draw2i(73,30); 
move2i(60,35); 
draw2i(67,30); 

color(853); 
rectfi(20,85,40,185); 
rectfi (50,85,70, 185); 
rectfi(80,85,100,185); 
color(BLACK); 
recti(20,85,40,185); 
recti(50,85,70,185); 
recti(80,85,100,185); 

color(853); 
circfi( 160, 165,20); 
circfi(l60, 110,20); 
circfi(220,165,20); 
circfi(220, 110,20); 
color(BL ACK); 
circi(l60, 165,20); 
circi(160,110,20); 
circi(220, 165,20); 
circi(220, 110,20); 
color(VVHITE); 
cmov2i( 147,160); 
charstr(”SPD"); /* label dials */ 
cmov2i( 147,106); 
charstrC’DIR”); 
cmov2i(207,106); 
charstr(”ALT”); 
cmov2i(207, 160); 
charstr(”CLR”); 

cmov2i(25,170); 

charstr(”Z”); /* label mouse buttons */ 

cmov2i(25,158); 

charstrC'O”); 

cmov2i(25,146); 

charstr("0"); 

cmov2i(25,134); 

charstrC’M"); 

cmov2i(25,l 10); 

charstr(”I”); 

cmov2i(25,98); 

charstr(”N'’); 



/* draw arrow */ 



/* dark brown * / 

/* draw mouse buttons */ 



/* outline buttons 



/* draw dials 



/* outline dials 
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cmov2i(55,170); 

charstr(”D’'); 

cmov2i(55,158); 

charstr(”E”); 

cmov2i(55,146); 

charstr(”S”); 

cmov2i(55,134); 

charstr(”I"); 

cmov2i(55,122); 

charstr("G'*); 

cmov2i(85,170); 

charstr(’»Z”); 

cmov2i(85,158); 

charstr("0"); 

cmov2i(85,146); 

charstr(”0”); 

cmov2i(85,134); 

charstr("M"); 

cmov2i(85,110); 

charstr("0"); 

cmov2i(85,98); 

charstr(”U”); 

cmov2i(85,86); 

charstr("T”); 



popmatrix(); 

closeobjO; 



MAKEMAP 



/* makemap.c - this function is called by the FOG-M missile simulator to 
build an object containing a contour map. The map is used for the full 
screen display in prelaunch, and in the upper right corner of the flight 
display in fogm. */ 

^include ”gl.h” 

^include "fogm.h” 

^include "device. h’^ 

makemap(contour) 

Object ^contour; 

{ 

short i, j, elev, length, lastcolor, breakpt|l5]; 
int colour; 

extern short gridpixeljl00j[l00j; /* terrain elevations & vegetation */ 

/* compute elevations where color changes should occur */ 

for (i - 1; i < 16; i+ + ) breakpt[i-l] = (((MAX - MIN) / 16 ) * i) + MIN; 

^contour = genobj(); /* create the navigation contol and display object */ 

makeobj(*contour); 

viewport (0,767, 0,767); 

pushmatrix(); 

ortho2(0. 0,100.0,0.0,100.0); /* use array index space */ 

color(BLACK); 

clear(); 

lastcolor = BLACK; 
linewidth(8); 

for (i=0; i < 100; -h+i) { /* draw column i */ 

move2i(i,0); /* start at bottom of column */ 

length = 0; /* f adjacent points of the same color * / 

for (j = 0; j < 100; +-Hj) { /* for each row in column i */ 

elev = gridpixel|j][i] &: elev mask; /* mask off* veg code * / 
if (elev < breakpt|0]) colour = 16; /* assign green colors * / 

else if (elev < breakpt|l]) colour =17 
else if (elev < breakpt|2]) colour = 18 
else if (elev < breakpt|3]) colour = 19 
else if (elev < breakpi|4]) colour = 20 
else if (elev < breakpt|5]) colour = 21 
else if (elev < breakpt[6]) colour = 22 
else if (elev < breakpt[7]) colour = 23 
else if (elev < breakpt[8]) colour = 24 
else if (elev < breakpt[9]) colour = 25 
else if (elev < breakptjlO]) colour = 26 
else if (elev < breakpt[ll]) colour = 27 
else if (elev < breakpt[l2|) colour = 28 
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else if (elev < breakpt[13|) colour = 29; 
else if (elev < breakpt[l4]) colour = 30; 
else colour = 31; 

/* if veg-code = 0 (i.e. veg < 1 meter) shift to brown colors */ 
if (!((gridpixel[j][i) >> 13) &: veg_mask)) colour += 16; 

if (colour == lastcolor) length + + ; /* don’t draw yet */ 

else { /* draw now that color has changed */ 

color(lastcolor); 
rdr2i(0, length); 

lastcolor = colour; /* reset for new draw */ 

length = 1; 

} 

} /* end for j */ 

color(colour); /* draw last (top) line */ 

rdr2i(0, length); 

} /* end for i */ 

if (!TV) { 

color(BLACK); /* draw grid on top of map */ 

linewidth(l); 



for (i = 10; i < 100; i^=10) { /* draw interior lines */ 
move2i(i,0); /* horizontals */ 

draw2i(i,100); 

move2i(0,i); /* verticals */ 

draw2i(l00,i); 

} 

} 

linewidth(2); /* draw exterior border */ 

rect(0.0, 0.0, 100.0, 100.0); 

popmatrix(); 

closeobjO; 
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MAKESCREENS 



/* makescreens.c - builds graphical objects for prelaunch’s instructional 
screens and readout boxes. * j 

^include "gl.h” 

^include ’’device. h" 

^include ’’fogm.h” 

makescreens(obj,tag) 

Object obj|7]; 

Tag lag[6]; 

{ 



obj|INSTR] = genobJO; /* object for pre-launch instructions */ 

makeobj(obj IN'STR]); 

if (TV) viewport(475,635,239,474); 

else viewport (767, 1023,3 85, 767); 

pushmatrix(); 

ortho2(0.0,255.0,0.0, 384.0); 

color(CYAN); 

clear(); 

color(BLUE); 

rectfi(10,10,245,374); 

color(WHITE); 

cmov2i(30,340); 

charstr("PRE-LAUNCH INSTRUCTIONS"); 

cmov2i(25,300); 

charstr('T. PRESS LEFT MOUSE"); 

cmov2i(52,285); 

charstr("BUTTON TO LOCK IN"); 
cmov2i(52,270); 

charstr("LAUNCH POSITION"); 
cmov2i(25,220); 

charstr("2. PRESS RIGHT MOUSE"); 
cmov2i(52,205); 

charstrC'BUTTON TO LOCK IN"); 
cmov2i(52,190); 

charstrC'TARGET LOCATION"); 
cmov2i(25,140); 

charstr("3. PRESS MIDDLE MOUSE"); 
cmov2i(52,125); 

charstrC'BUTTON TO LAUNCH"); 
cmov2i(25, 75); 

Charstr("4. PRESS ALL THREE"); 
cmov2i(52, 60); 

charstrC'BUTTONS TO EXIT"); 

popmatrLx(); 

closeobjO; 



198 



/* define object for displaying user input for missile launch 

position and target location. Also displays computed heading 
and distance to target */ 

obj[STATS] = genobJO; 

makeobj(obj[STATS]); 

if (TV) viewport(475, 635, 0,238); 

else viewport(767, 1023, 0,384); 

pushmatrix(); 

ortho2(0.0,255.0,0.0,384.0); 

color(CYAN); 

clear(); 

color(BLUE); 

rectfi(l0,10,245,374); 

color (WHITE); 

cmov2i(30,340); 

charstr(”PRE-LAUNCH STATISTICS”); 
cmov2i(25,260); 

charstr("LAUNCH POSITION: lOSFQ”); 

cmov2i(70,235); 

charstr(”X COORD: ”); 

cmov2i(70,220); 

charstr(”Y COORD: ”); 

cmov2i(170,235); 

tag[LAUNCH] = gentagO; 

maketag(tag[LAUNCH]); 

charstr(” ”); 

cmov2i(l70,220); 

charstr(” ”); 

cmov2i(25,180); 

charstr(”TARGET LOCATION: lOSFQ”); 

cmov2i(70,155); 

charstr(”X COORD: ”); 

cmov2i(70,140); 

charstr(”Y COORD: "); 

cmov2i(170,155); 

tag[TARGET] = gentag(); 

maketag(tag[TARGET]); 

charstr(” ”); 

cmov2i(170,140); 

charstr(” ”); 

cmov2i(25,100); 

charstr(” HEADING: ”); 

cmov2i(25,60); 

charstr(”DISTANCE: ”); 

cmov2i(106,100); 

tag[HEAD] = gentagO; 

maketag(tag[HEAD]); 

charstr(” ”); 

cmov2i(115,60); 

charstr(” ”); 

popmatrix(); 
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closeobjO; 

/* define object for lines & circles showing flightpath on contour map */ 

obj(FLTPATH] = genobJO’; 

makeobj(obj(FLTPATH]); 

pushmatrix(); 

if (TV) viewport(0, 474, 0,474); 

else viewport(0, 767, 0,767); 

ortho2(0.0,100.0,0.0,100.0); 

color(BLACK); 

cleax(); 

color(64); 

linewidth(3); 

tag[MISSILE] = gentagO; 
maketag(tag[MISSILE]); 
circf(0. 0,0. 0,0.0); 
move2(0.0, 0.0, 0.0); 
draw2(0.0, 0.0, 0.0); 
color(l28); 

tag(TGT] = gentagO; 

maketag(tag(TGT)); 

circf(0.0,0.0,0.0); 

popmatrix(); 

closeobJO; 

/* define object for displaying first screen of operator instructions * j 

obj[SCREENl] = genobjO; 
makeobj (obj (SCREEN 1 ] ) ; 

color(BLUE); /* set background color */ 

clear(); 

color(RED); 

linewidth(lO); 

recti(0,0,1023,767); 

linewidth(l); 

color(WHITE); 

cmov2i(420,500); 

charstr("WELCOME"); 

cmov2i(420,450); 

charstr("TO THE”); 

cmov2i(320,400); 

charsir('»FIBER-OPTICALLY GUIDED MISSILE”); 

cmov2i(420,350); 

charscr(”(FOG-M)”); 

cmov2i(4 10,300); 

charstr(”SIMULATION”); 

cmov2i(310,100); 

charstr(”PRESS MIDDLE MOUSE BUTTON TO CONTINUE...”); 
cmov2i(315,85); 

charstr(”OR PRESS ALL 3 MOUSE BUTTONS TO EXIT.”); 
closeobjO; 
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/* define object for displaying second screen of operator instructions */ 



obj[SCREEN2] = genobj(); 
makeobj(obj[SCREEN2]); 

color(BLUE); /* set background color * / 

clear(); 

linewidth(lO); 

color(RED); 

recti(0, 0,1023, 767); 

linewidth(l); 

color (WHITE); 

cmov2i(210,600); 

charstr('THE FOG-M PROGRAM PROVIDES A SIMULATED MISSILE LAUNCH AND"); 
cmov2i(210,575); 

charstr("OUT-THE. WINDOW VIEW OF THE TERRAIN AS SEEN FROM THE OPERATOR’S"); 
cmov2i(210,550); 

charstr("CONSOLE ON THE GROUND."); 
cmov2i(210,500); 

charstr("THE GENERAL AREA FOR THIS FLIGHT SIMULATION IS FT HUNTER LIGGETT"); 
cmov2i(210,475); 

charstr("CALIFORNIA AND VICINITY."); 
cmov2i(210,425); 

charstr("THE SPECIFIC TEST AREA IS A 10 KILOMETER REGION DESIGNATED BY"); 
cmov2i(210,400); 

charstr("UNIVERSAL TRANSVERSE MERCATOR (UTM) GRID COORDINATES 10SFQ58."); 
cmov2i(300,100); 

charstr("PRESS MIDDLE MOUSE BUTTON TO CONTINUE,"); 
cmov2i(305,85); 

charstr("OR PRESS ALL 3 MOUSE BUTTONS TO EXIT."); 
closeobJO; 



/* define object for displaying third screen of operator instructions */ 



obj[SCREEN3] = genobj(); 
makeobj(obj[SCREEN3]); 

color(BLUE); /* set background color */ 

clear(); 

linewidth(lO); 

color(RED); 

recti(0,0,1023,767); 

linewidth(l); 

color(WHITE); 

cmov2i(385,650); 

charstr("PRE-LAUNCH ORIENTATION"); 
cmov2i(200,600); 

charstr("l. WHEN THE PRE-LAUNCH PHASE OF THE FOG-M SIMULATION BEGINS, A"); 
cmov2i(200,585); 

charstr("2-DIMENSIONAL CONTOUR MAP OF THE TEST AREA (UTM 10SFQ58) WILL BE"); 
cmov2i(200,570); 

charstr("DISPLAYED ON THE OPERATOR CONSOLE. TWO CONTROL PANELS CONTAINING"); 
cmov2i(200,555); 

charstr("PRE-LAUNCH INSTRUCTIONS AND CURRENT LAUNCH STATISTICS WILL ALSO"); 
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cmov2i(200,540); 
charstr("BE DISPLAYED."); 
cmov2i( 200,490); 

charstr("2. THE OPERATOR WILL BE REQUIRED TO PROVIDE TWO CRITICAL DATA"); 
cmov2i(200,475); 

charstr(" ITEMS TO THE LAUNCH CONTROL SYSTEM; INITIAL LAUNCH POSITION AND"); 
cmov2i(200,460); 

charstrC'TARGET LOCATION."); 
cmov2i(200,410); 

charstr("3. TO DEFINE INITIAL LAUNCH POSITION, MOVE CURSOR OVER DESIRED"); 
cmov2i(200,395); 

charstr("LOCATION (REFER TO LAUNCH STATISTICS CONTROL PANEL TO VIEW THE"); 
cmov2i(200,380); 

charstrC'CURRENT UTM GRID COORDINATES). PRESS LEFT MOUSE BUTTON TO LOCK") 
cmov2i(200,365); 

charstrC'IN LAUNCH POSITION."); 
cmov2i(200,315); 

charstr("4. TO DEFINE TARGET LOCATION, MOVE CURSOR OVER DESIRED LOCATION") 
cmov2i(200,300); 

charstr(" (REFER TO LAUNCH STATISTICS CO.NTROL PANEL TO VIEW CURRENT UTM"); 
cmov2i (200,285); 

charstr("GRID COORDINATES). PRESS RIGHT MOUSE BUTTON TO LOCK IN TARGET"); 
cmov2i(200.270); 

charsirC’LOCATION. THE BLUE LINE DISPLAYS THE PROJECTED FLIGHT P.ATH. THE"); 
cmov2i(200,255); 

charstrC'MISSILE WILL FLY AT A CONSTANT VELOCITY AND HEADING. THE LAUNCH"); 
cmov2i(200,240); 

charstrC'STATISTICS CONTROL PANEL WILL DISPLAY COMPUTED MISSILE HEADING"); 
cmov2i(200,225); 

charstrC'IN DEGREES (0 DEGREES DUE NORTH)."); 
cmov2i(240,100); 

charstr("PRESS MIDDLE MOUSE BUTTON TO MOVE INTO PRE-LAUNCH PHASE,"); 
cmov2i(326,85); 

charstrC'OR PRESS ALL 3 MOUSE BUTTONS TO EXIT."); 
closeobjO; 
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MAKETANK 



^include ”gl.h” 
^include "fogm.h” 

maketank(item) 
Object *item; 

{ 



long points = 4, bigpoints = 8; 
float paxray[8][3]; 
float Lx,ly,lz; 

long cmin = MIN TGT_COLOR, cmax = MAX_TGT_COLOR, cl; 
lx = 400.0 * 41.01; /* direction of lightsource */ 

ly = 6000.0; 

Iz = 200.0 * (-41.01); 



*item=genobj(); 

makeobj(*item); 

/* draw right side of tank CCW */ 

parray[0][0] = -10.0; 

parrayjojjl] = 6.0; 

parray[oj[2] = -5.0; 

parrayjljjoj = -15.0; 

parrayjljjlj = 4.0; 

parray[lj[2] = -5.0; 

paxray[2][0] = -15.0; 

parray[2l[lj = 2.0; 

parray(2j(2] = -5.0; 

parray[3][0] = -10.0; 

parray[3][l] = 0.0; 

parray(3][2] = -5.0; 

paj‘ray(4](0] = 10.0; 

parray[4][l] = 0.0; 

parray[4][2] = -5.0; 

parray[5j[0l = 15.0; 

parray|5][l| — 2.0; 

parrayj5|[2| = -5.0; 

parray[6j[oj — 15.0; 

parray[6][l] = 4.0; 

parray[6][2] = -5.0; 

parray[7][oj = 10.0; 

parray[7][lj = 6.0; 

parray[7][2] = -5.0; 

lightorient(parray, bigpoints, 0.0,0. 0,0.0, lx, ly,lz, cmin, cmax, A:cl); 
color(cl); 
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polf(bigpoints,parray) ; 

/* front of tank CW */ 
parray[0][0] = 15.0; 
pajTayjojjl] = 5.0; 
pajTay[0][2] = -5.0; 
paLTrayjljjoj = 15.0; 
parrayjljjl] = 3.0; 
parray[l][2] = -5.0; 
parray[2][0] = 15.0; 
parray[2][l] = 3.0; 
parray[2)[2] = 5.0; 
pajTay[3][0] = 15.0; 
parray[3][l] = 5.0; 
pajTay[3][2] = 5.0; 

lightorient(parray,points,0.0,0.0j0.0,lx,ly,lz,cmin,cmax,&:cl); 

color(cl); 

polf (points, parray) ; 



/* draw left side of tank CW */ 
pajTay[0][0| = 10.0; 
parrayjojjl] = 6.0; 
parray[oj(2] = 5.0; 
parray(l![oj = 15.0; 
pajrayjljjlj = 4.0; 
parray[l][2| = 5.0; 
parray[2][0] = 15.0; 
parray[2][lj = 2.0; 
parray[2][2] = 5.0; 
pajTay[3][0] = 10.0; 
parray[3][l] = 0.0; 
parray[3][2] = 5.0; 
parray [4] [0| = -10.0; 
parray[4][l] = 0.0; 
parray[4][2] = 5.0; 
parray|5][0] = -15.0; 
parray[5][l] = 2.0; 
parray[5][2] = 5.0; 
pajTay[6][0] = -15.0; 
parray[6][l] = 4.0; 
parray[6][2] = 5.0; 
parray[7l[0l = -10.0: 
parrayi 7|[l( - 6.0; 
parrayi 7|f2i — 5.0; 

lightoneru(parray,bigpoints,0.0,G.0,0.0,lx,iy,lz,cmin,cmax,^!^cl); 

color(cl); 

polf(bigpoints, parray); 



/* back of tank CCW */ 
parray[0|[0] = -15.0; 
parrayjojjl] = 4.0; 
parray jojj2j = 5.0; 
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parray[l][0] = -15.0; 
parrayjljjl] = 2.0; 
parray[l][2] = 5.0; 
parray[2][0] = -15.0; 
parray[2][l] = 2.0; 
parray[2][2] = -5.0; 
parray[3][0] = -15.0; 
parray[3][l] = 4.0; 
parray[3][2] = -5.0; 

lightorient(parray, points, 0.0, 0.0, 0.0, lx, ly,lz,cmin,cmajc,&cl); 
color(cl); 

polf(points,parray) ; 

/* top middle of tank body CCW */ 

parray[0][0] = -10.0; 

parray[0][l] = 6.0; 

parray[0][2] = -5.0; 

parrayjljjo] = -10.0; 

parray[ll[l] = 6.0; 

parray[lj[2] = 5.0; 

parray[2][0] = 10.0; 

parray[2][l] = 6.0; 

parray[2l[2] = 5.0; 

parray[3j[0) = 10.0; 

parray[3][l] = 6.0; 

parray[3][2] = -5.0; 

lightorient (parray, points, 0.0, 0.0, 0.0, lx, ly,lz,cmin,cmax, &cl); 
color(cl); 

polf(points,parray); 

/* top front of tank body CCW */ 

parray[0][0] = 10.0; 

parrayjojjl] = 6.0; 

parray[0][2] = -5.0; 

parrayjljjo] = 10.0; 

parrayjljjlj = 6.0; 

parrayjljj2j = 5.0; 

parrayj2]joj = 15.0; 

parrayj2jjlj = 4.0; 

parrayj2]j2] = 5.0; 

parrayj3jjoj = 15.0; 

parrayf3l[l| = 4.0: 

parrayt3i[2l — -5.0; 

lightorienc(parray, points, 0.0, 0.0, 0.0, lx, ly,lz,cmin,cmax,&cl); 
color(cl); 

polf (points, parray) ; 

/* top back of tank body CCW * j 
parray[0][0] = -10.0; 
parrayjojjl] = 6.0; 
parrayjojj2j = -5.0; 
parrayjljjoj = -15.0; 
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parray[l|[l] = 4.0; 
parray[l][2] = -5.0; 
parray[2][0| = -15.0; 
parray[2][l| = 4.0; 
parray[2][2] = 5.0; 
parray[3][0] = -10.0; 
parray[3][l] = 6.0; 
parray[3][2] = 5.0; 

lightorient(parray, points, 0.0, 0.0, 0.0, lx, ly,lz,cmin,cmax,&cl); 
color(cl); 

polf(points,parray); 

/* bottom middle of tank CW*/ 
parray[0][0| = -10.0; 
parrayjojjlj = 0.0; 
parray[0][2] = -5.0; 
parray[l][0] = 10.0; 
parrayjljjlj = 0.0; 
parray[l][2] = -5.0; 
parray[2][0] = 10.0; 
parray[2][l] = 0.0; 
parray[2|[2] = 5.0; 
parray[3][0] = -10.0; 
parrayj3][l] = 0.0; 
parray[3|[2] = 5.0; 

lightorien t(parray,points,0.0,0. 0,0.0, lx, ly,lz,cmin,cmax,&cl); 
color(cl); 

polf(pointSjparray); 

/* bottom front of tank CW */ 
parray[0|[0| = 10.0; 
parray[0|[l] = 0.0; 
parray[0][2| = -5.0; 
parray[l][0] = 15.0; 
parray[lj[l] = 2.0; 
parray[l][2| = -5.0; 
parray[2][0| = 15.0; 
parray[2j[l] = 2.0; 
parray[2][2| = 5.0; 
parray[3][0| = 10.0; 
parray[3][l] = 0.0; 
parray[3l[2l — 5.0; 

lightonent(parray,pomts,0.0,0.0,0.0,Lx,ly,lz,cmm,cmax,v^cl); 

coior(cl); 

polf(points,parray); 

/* bottom back of tank CW */ 
parray[0][0] = -10.0; 

parrayjojjlj = 0.0; 
parrayjojj2j = -5.0; 
parrayjl][0] = -10.0; 

parrayjljjlj = 0.0; 
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parray[l][2] = 5.0; 
parray[2][0] = -15.0; 

parray[2][l] = 2.0; 
parray[2][2] = 5.0; 
parray[3][0] = -15.0; 

parray[3][l] = 2.0; 
parray[3][2] = -5.0; 

lightorient(parray, points, 0.0, 0.0, 0.0, Lx, ly,lz,cmin,cmgix,&cl); 
color(cl); 

polf(points,parray); 

/* right side of gun barrel */ 
parray[0][0] = 1.6667; 
parray[0][l] = 8.0; 
parray[0][2] = -0.5; 
parray[l][0] = 2.3333; 
parrayjljjl] = 7.0; 
parray(l](2] = -0.5; 
parray(2l[0] = 17.0; 
parray[2j[l] = 7.0; 
parray(2][2] = -0.5; 
parray(3](0] = 17.0; 
parray(3][l] = 8.0; 
parray[3j[2] = -0.5; 

lightorient(parray,points,5.0,2.5,0.0,Lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

/* top of gun barrel */ 
parray[0][0] = 1.6667; 
parrayjojjl] = 8.0; 
parray[0][2] = 0.5; 
parray(l](0] = 1.6667; 
parrayjljjl] = 8.0; 
parrayjljj2j = -0.5; 
parray(2][0] = 17.0; 
parrayj2]jlj = 8.0; 
parrayj2jj2j = -0.5; 
parray[3][0] = 17.0; 
parray[3jjlj = 8.0; 
parrayj3jj2j = 0.5; 

lightorient(parray.points,5.0,2.5,0.0,lx,ly,lz,cinin,cmax,&:cl); 

coior(cl); 

polff points, parr ay); 

/* left side of gun barrel */ 
parray[0][0] = 17.0; 
parrayjojjlj = 8.0; 
parray[0][2] = 0.5; 
parrayjljjoj = 17.0; 
parrayjljjl] = 7.0; 
parrayjljj2j = 0.5; 
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parray[2][0] = 2.3333; 
parray[2][l] = 7.0; 
parray[2][2] = 0.5; 
parray[3][0] = 1.6667; 
parray[3][l] = 8.0; 
paLrray[3][2| = 0.5; 

lightorient(parray,points.5.0,2.5,0.0,Lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

/* end of gun barrel */ 
parray[0)[0] = 17.0; 
parrayjojjl] = 8.0; 
parray[0][2) = -0.5; 
parray[l][0] = 17.0; 
parray[l][l] = 7.0; 
parray[l][2] = -0.5; 
parray[2][0] = 17.0; 
parray[2][l] = 7.0; 
parray[2j[2] = 0.5; 
parray[3][0] = 17.0; 
parray(3][l] = 8.0; 
parray[3)[2] = 0.5; 

lightorient(parray, points, 5.0,2. 5,0.0, lx, ly,iz,cmin,cmax,<Szcl); 
color(cl); 

polf( points, parray); 

/^bottom of gun barrel */ 
parray [0][0] = 2.3333; 
parrayjojjl] = 7.0; 
parrayjojj2j = 0.5; 
parray[l][0| = 2.3333; 
parray[l][l] = 7.0; 
parray[l][2] = -0.5; 
parray [2] [0] = 17.0; 
parray[2][l] = 7.0; 
parray j2jj2j = -0.5; 
parray [3] [0] = 17.0; 
parray [3] [l] = 7.0; 
parray j3|j2j = 0.5; 

lightorient(parray,points,5.0,2.5,0.0,lx,ly,lz,cmin,cmax,<Szcl); 

color(cl); 

poiffpoints, parray); 

right side of turret 
parray[0][0| = -3.0; 
parrayjojjl] = 9.0; 
parray[0][2] = -1.0; 
parrayjljjoj = -5.0; 
parrayjljjlj = 6.0; 
parrayjljj2j = -3.0; 
parray j2]joj = 3.0; 
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parray[2][l] = 6.0; 
parray[2][2] = -3.0; 
parray[3][0] = 1.0; 
parray[3][l] = 9.0; 
parray[3][2] = -1.0; 

lightorient(paxray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

po If (points, parray); 

/* front side of turret */ 
paj*ray(0][p] = 1.6667; 
parrayjojjl] = 9.0; 
pajray[0](2] = -1.0; 
parray(l][0] = 3.0; 
parrayjljjl] = 6.0; 
parray(l](2] = -3.0; 
paj*ray(2][0] = 3.0; 
parray(2](l] = 6.0; 
parray[2](2] = 3.0; 
parray[3][0] = 1.6667; 
parray[3][l] = 9.0; 
parray[3][2] = 1.0; 

lightorient(parray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

/* left side of turret */ 
parray[0][0] = 1.6667; 
parrayjojjl] = 9.0; 
parrayjojj2j = 1.0; 
parrayjljjoj = 3.0; 
parrayjljjl] = 6.0; 
parrayjljj2j = 3.0; 
parrayj2jjoj = -5.0; 
parrayj2jjlj = 6.0; 
parrayj2j[2j = 3.0; 
parrayj3jjoj = -3.0; 
parrayj3]jlj = 9.0; 
parrayj3j[2] = 1.0; 

lightorient{parray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray); 

* back side of turret '*'/ 
parray[0][0] = -3.0; 
parrayjojjl] = 9.0; 
parrayjojj2j = 1.0; 
parrayjljjoj = -5.0; 
parrayjljjl] = 6.0; 
parrayjljj2j = 3.0; 
parrayj2jjoj = -5.0; 
parrayj2jjlj = 6.0; 
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parray[2][2] = -3.0; 
parray[3][0] = -3.0; 
parray[3][l] = 9.0; 
parray[3][2] = -1.0; 

lightorient(parray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,&cl); 

color(cl); 

polf(points,parray) ; 

/* top of turret */ 
parray[0][0] = -3.0; 
parrayjojjl] = 9.0; 
parray[0][2l = 1.0; 
parrayjljjo) = -3.0; 
parray[l][l] = 9.0; 
parray[l][2] = -1.0; 
parray[2][0] = 1.0; 
parray[2][l] = 9.0; 
parray[2][2] = -1.0; 
parray[3][0] = 1.0; 
pajray[3][lj = 9.0; 
parray[3][2] = 1.0; 

lightorient(parray,points,-1.0,2.5,0.0,lx,ly,lz,cmin,cmax,<&^cl); 

color(cl); 

polf (points, parray) ; 
closeobjO; 
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NEAREST TGT 



^include "gl.h^* 

^include *Togm.h^^ 

neaxest_tgt(vx,vy,vz,px,py,pz,tgt_idx) 

Coord vx, vy, vz, px, py, pz; 
int *tgt_idx; 

{ 

float dist, dist_to_los(); 
float min_dist; 
float numjtgts; 

extern float tgt_pos[MAX_TGTS][3]; 
int index; 

num tgts = 10; 

min_dist = dist_^to_los(vx,vy,vz,px,py,pz,&tgt_pos[0][0]); 
*tgt_idx = 0; 

for (index = 1; index < num^tgts; -h-findex) { 

dist = dist_to_los(vx,vy,vz,px,py,pz,<ktgt_pos[index][0]); 
if (dist < min_dist) ( 
min dist = dist; 

*tgt_idx = index; 

} 

} 

} 
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NPOLY ORIENT 



/* npoly_orient.c * j 

^include <gl.h> 

:#include <math.h> 

int npoly^orient (ncoords,xyz,xinside,y inside, zinside) 
unsigned int ncoords; 

Coord xyz[][3]; 

Coord xinside, yinside, zinside; 

{ 



register unsigned short int i,j; /* loop temps */ 

Coord center[3]; /* center coordinate of the polygon */ 

Coord a[3], b[3j; /* vector hold locations for the vectors that run 
from the center coordinate to the points of the 
polygon */ 

Coord xn[3], xmn[3]; /* points on line containing normal that are 
on opposite sides of the plane containing 
the polygon. 

7 

float distton; /* distance to point n from pt inside. * / 
float disttomn; /* distance to point -n from pt inside. * / 

Coord normal[3); /* the normal vector computed from a x b */ 



/* compute the center coordinate of the polygon * / 
centerjO] = 0.0; 
centerjl] = 0.0; 
center[2] = 0.0; 

for(i=0; i < ncoords; i-h-h) 

{ 

forfj=0; j < 3; 

{ • 

cencerjjl 4.= xyz|i)(jl; 

} 

} 

/* divide out by the number of coordinates */ 
for(j=0; j < 3; j+-h) 

{ 

center[j] = center[j]/(float)ncoords; 

} 
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/* check the first 2 coordinates of the polygon for their direction */ 



/* compute vector a. It runs from the center coordinate to coordinate 0 */ 
for(j=0; j < 3; j++) 

{ 

a[j] = xyz[0][j] - center[j]; 

} 

/* compute vector b. It runs from the center coordinate to coordinate 1 */ 
for(j=0; j <3; j++) 

{ 

b[jl = xyz[l][j] - center[j]; 

} 

/* compute a X b to get the normal vector */ 
normal[0] = a[l]*b[2] - a[2]*b[l]; 
normaljl] = a[2]*b[oj - a[0]*b[2]; 
normal[2] = a[0]*b[l] - a[l]*b[0]; 

/* compute point n, offset pt from center in direction of normal */ 
for(j=0; j < 3; j++) 

{ 

xn[j] = center(j] + normal[j]; 

} 

/* compute point -n, offset pt from center in opposite direction 
from normal. 

*/ 

for(j=0; j < 3; j++) 

{ 

xmn[j] = centerjj] - normal[j]; 

} 

/* compute the distance the inside pt is from point n */ 
distton = sqrt((xn[0] - xinside) * (xn[0] - xinside) H- 
(xn[l] - yinside) * (xn[l] - yinside) H- 
(xn[2] - zinside) * (xn[2] - zinside)); 

/* compute the distance the inside pt is from point -n */ 
disttomn = sqrt((xmn[0] - xinside) * (xmn[0] - xinside) + 

(xmn[l] - yinside) * (xmn[l] - yinside) -h 
(xmn[2j - zinside) * (xmnf2] - zinside)); 
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/* if the dist(n) < dist(-n), then n points back towards the 
inside point and is on the same side of the plane as inside, 
a X b is then clockwise. 

. 7 

if(distton < disttomn) 

{ 

return(l); /* clockwise */ 

} 

else 

{ 

return(O); /* counterclockwise */ 

} 



} 
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PRELAUNCH 



/* The function prelaunch is the user interface portion of the FOG-M 
flight simulation. It allows the operator to interactively enter 
critical data items necessary to simulate the missile in flight. 

The function returns the initial launch position in the x-z plane 
and also the direction of flight. */ 



^include ”gl.h” 

^include ”device.h” 

^include ”fogm.h” 

^include ’’math.h” 

prelaunch(vx, vy, vz, direction, compassdir, active, obj, tag) 

Coord *vx, *vy, *vz; 
double *direction; 
float *compassdir; 
int *active; 

Object obj [7]; 

Tag tag[6]; 

{ 

float gnd_level(); 
float compass(); 

int screencnt, launchlock, targetlock; 

int xval, yval, xlaunch, ylaunch, xtarget, ytarget, utm x, utm y 
char xtemp[35], ytemp[35], dist[35j, heading[35]; 
float distance; 

double xdistance, ydistance; 

Colorindex unmask; 

xtemp[0] = ’ ’; 
ytemp[0] = ’ 
dist[0] = ’ ’; 
heading[0] = ’ ’; 

unmask=(l<<getplanes()) -1; 
writemask(unmask); 

.if (TV) viewport(0, 635. 0,474); 
else viewport(0, 1023, 0,767); 
pushmatrix(); 

orcho2(0.0, 1023.0, 0.0,767.0); 

*direction = 0.0; /* initialize the direction */ 

cursofF(); /* turn the cursor off */ 

caIlobj(obj[SCREENl]); /* display screen 1 */ 

swapbuffers(); 



215 



screencnt = 1; 



/* initialize counter for screen displays * / 



while(TRUE) { 

frontbufFer(TRUE) ; 

if (getbutton(MOUSE2) && !(getbutton(MOUSEl)) && !(getbutton(M0USE3))) { 
ringbellO; 

while (getbutton(MOUSE2)); 
screencnt -f-= 1; 

if (screencnt == 2) callobj(obj[SCREEN2]); 
else if (screencnt == 3) callobj(obj[SCREEN3]); 
else break; 

} 

if (getbutton(MOUSEl) (getbutton(MOUSE2)) && (getbutton(MOUSE3))) { 

* active = FALSE; 
goto exit; 

} 

} 

frontbuffer (FALSE); 

editobj(obj[FLTPATH]); erase previous missile path */ 

objreplace(tag[MISSILE]); 

circf(0.0, 0.0, 0.0); 

move2(0.0, 0.0); 

draw2(0.0, 0.0); 

objreplace(tag[TGT]); 

circf(0.0, 0.0, 0.0); 

closeobjO; 

editobj(obj[STATS]); /* erase previous launch statistics */ 

objreplace(tag[HEAD]); 

charstr(""); 

cmov2i(115,60); 

chaxstr(""); 

objreplace(tag[TARGET]); 

chaxstr(””); 

cmov2i(0,0); 

charstr(”"); 

closeobjO; 

setcursor(0, RED, unmask); /* set up cursor and mouse */ 

attachcursor(MOUSEX,MOUSEY); 

setvaluator(MOUSEX,384,0,767); 

:^etvaiuator| MOUSEY, 384.0,767); 
curson(); 

launchlock = FALSE; 
targetlock = FALSE; 

callobj(obj [CONTOUR]); /* load static displays into both buffers */ 
callobj(obj[INSTR|); 

callobj(obj [STATS]); /* included so swapped buffer doesn’t have "hole" */ 
swapbuffers(); 
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callobj(obj[CONTOUR]); 

callobj(obj[INSTR]); 

while(TRUE) { 

if (getbutton(MOUSEl) && (getbutton(MOUSE2)) && (getbutton(MOUSE3))) { 
*active = FALSE; 
goto exit; 

} 

xval = getvaluator(MOUSEX); /* read the x and y mouse positions */ 

yval = getvaluator(MOUSEY); 

utm_x = (50000 -f (int)(xval * GRID^FACTOR)); /* compute grid coordinates */ 

utm_y = (80000 -H (int)(yval * GRID^FACTOR)); 

sprintf(xtemp,"%4d",utm__x); /* store coordinates in temporary buffer */ 

sprintf(ytemp,"%4d",utm_y); 

/* if LEFT MOUSE selected lock in launch position and update control panel */ 

if (getbutton(MOUSE3) && (!getbutton(MOUSE2)) && (Igetbutton(MOUSEl))) { 
ringbell(); 
xlaunch = xval; 
ylaunch = yval; 
launchlock = TRUE; 

*vx = ((float)((xval * FT J0K)/767)); 

*vz = -((float) ((yval * FT_10K)/767)); 

*vy = gnd Jevel(*vx, *vz) + 200.0; 

editobj(obj[STATS]); 

objreplace (tag [LAUNCH]); 

charstr(xtemp); 

cmov2i(l70,220); 

charstr(ytemp); 

closeobjO; 

} /* end of MOUSE3 hit */ 

/* As long as LEFT MOUSE not selected, keep on displaying current UTM 
grid coordinates in control panel area. */ 

if (llaunchlock) { 

editobj(obj[STATSj); 

objreplace(tag|LAUNCH|); 

charstr(xtemp); 

cmov2i( 170,220); 

chcirstr(ytemp); 

closeobjO; 

} 

/* if RIGHT MOUSE selected lock in target and update control panel. */ 

if (getbutton(MOUSEl) kk (!getbutton(MOUSE3)) kk (!getbutton(MOUSE2))) { 
ringbell(); 
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xtarget = xval; 

ytarget = yval; 

targetlock = TRUE; 

editobj(obj[STATS]); 

objreplace(tag[TARGET]) ; 

charstr(xtemp); 

cmov2i(170,140); 

charstr(ytemp); 

closeobjO; 

} 

/* As long as RIGHT MOUSE not selected keep on displaying current UTM 
grid coordinates in control panel area. */ 

if (Itargetlock) { 

if (launchlock) { 

xdistance = ((double) (xval - xlaunch)); 
ydistance = ((double)(yval - ylaunch)); 

distance = sqrt((float) (xdistance * xdistance -h ydistance * ydistance)); 
distance = distance * GRID FACTOR; 
sprintf(dist/’%5.0f METERS”, distance); 

*direction = atan2(ydistance, xdistance); 
if (^direction < 0.0) *direction += TWOPI; 

*compassdir = compass(*direction); 

sprintf(heading,”%d DEGREES”, (int)*compassdir); 

editobj(obj [STATS]); 

objreplace(tag[TARGET|); 

charstr(xtemp); 

cmov2i(l70,140); 

charstr(ytemp); 

objreplace( tag [HEAD]); 

charstr( heading); 

cmov2i(115,60); 

charstr(dist); 

closeobjO; 

} 

} 

/* if launch position and target location have been selected by the 

operator compute the direction of the missile and distance to target. * / 

if (launchlock && targetlock) { 

xdistance — ((double) (xtarget - xiaunch)); 
ydistance = ((double)(ytarget - ylaunch)); 
distance = sqrt( (float) ((xdistance "" xdistance) — 

(ydistance * ydistance))); 
distance = distance * GRID_FACTOR; 
sprintf(dist,”%5.0f METERS”, distance); 

*direction = atan2(ydistance, xdistance); 
if (*direction < 0.0) *direction += TWOPI; 

*compassdir = compass(*direction); 
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sprintf(heading,"%d DEGREES", (int)*compassdir); 

editobj (obj [ST ATS] ) ; 

objreplace(tag[HEAD|); 

charstr(heading); 

cmov2i(115,60); 

charstr(dist); 

closeobjO; 

} 

/* add small red and blue circles to contour map to indicate launch 
position and target location. Connect circles to indicate missile 
flight path */ 

if (launchlock) 

if (targetlock) { 

editobj(obj[FLTPATH]); 
objreplace(tag[MISSILE)) ; 

circf((float)(xlaunch)/767. 0*100.0, (float) (ylaunch)/767. 0*100.0, 0.6); 
move2( (float) (xtarget)/767. 0*100.0, (float) (ytarget) /767.0* 100.0), * 
draw2( (float) (xlaunch) /767. 0*100.0, (float) (ylaunch)/767. 0*100.0); 
objreplace(tag[TGT]); 

circf( (float) (xtarget)/767. 0*100.0, (float) (ytarget)/767. 0*100.0, 0.6); 
closeobjO ; 

} 

else { 

editobj(obj[FLTPATH|); 
objreplace(tag[MISSILE|) ; 

circf( (float) (xlaunch) /767. 0*100.0, (float) (ylaunch)/767.0* 100.0, 0.6); 
move2((float)(xval)/767.0*100.0, (float)(yval)/767.0*100.0); 
draw2 ((float) (xlaunch)/767. 0*100.0, (float) (ylaunch) /767.0* 100.0); 
closeobjO; 

} 

/* if MIDDLE MOUSE selected, launch has occurred and control transfers 

back to main portion of FOG-M program displaying out-the-window 3-D 
view of the flight area. */ 

if (getbutton(MOUSE2) && (!getbutton(MOUSEl)) LL (!getbutton(MOUSE3)) 
&& launchlock && targetlock) { 
ringbell(); 

while (getbutton(MOUSE2)); 
break; 

} 
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writemask(SAVEMAP); 
callobj(obj[FLTPATH]); 
writemask (unmask); 
callobj(obj[STATS]); 
swapbuffers(); 

} 

exit: 

cursoff(); 

popmatrix(); 

} 
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RANDNUM 



I* randnum.c - returns a random float between zero and one */ 

static long seed = 1234567; 

randseed(newseed) 
long newseed; 

{ 

seed = newseed; 

} 



float randnum() 

{ 

long mult(); 

seed = (mult(seed, 31415821) + l) % 100000000; 
return (seed / 100000000.0); 

} 

long mult(p,qj 
long p,q; 

{ 

long pO, pi, qO, ql; 
pi = p / 10000; 

pO = p % 10000; 
ql = q / 10000; , 
qO = q % 10000; 

return((((p0*ql + pl*q0) % 10000) * 10000 + p0*q0) % 100000000); 

} 
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READCONTROLS 



/* reads the values from the operator’s controls (mouse and dials) */ 

^include *^gl.h^^ /* graphics lib defs */ 

^include *Togm.h^’ /* fogm constants */ 

^include ^device.h** /* device definitions */ 

read_controls(designate, greyscale, flying, active, speed, direction, 
compassdir, alt, pan, tilt, fovy) 

int *designate, *greyscale, *flying, ^active, *fovy; 
float *speed, *compassdir; 
double ^direction, *pan, *tilt; 

Coord *alt; 

{ 

extern float randx, randy, randz; 
float randnum(); 

Colorindex colors[l]; 

/* quit if all three mouse buttons are pushed */ 

if(getbutton(MOUSEl) getbutton(MOUSE2) Scic getbutton(MOUSEo)) { 

*flying = FALSE; 

^active = FALSE; 

} 

else { 

if (getbutton(MOUSE3) !(getbutton(MOUSE2))) { /* Zoom In */ 

*fovy = (*fovy < (80 -h DELTAFOVY)) ? 80 : *fovy - DELTAFOVY; 

. } 

if (getbutton(MOUSEl) && !(getbutton(MOUSE2))) { /* Zoom Out */ 

*fovy = (*fovy > (550 - DELTAFOVY)) ? 550 : *fovy + DELTAFOVY; 

} 

if (getbutton(MOUSE2)) { /* designate/reject target */ 

if (*designate) { /* see if target in sights */ 

/*pushmatrix(); 

pushviewport(); 

pushattributes(); 

viewport(0, 1023, 0, 767); 

ortho2(0.0, 1023.0, 0.0, 767.0); 

cmov2s((Scoord)(768/2), (Scoord)(768/2)); 

readpixels(l, colors); 

if ((colors[0] >= MIN_TGT_COLOR) && (colors[0] <= MAX_TGT_COLOR)) 
*designate = FALSE; 
ringbell(); 

randx = 30.0 * randnum() - 15.0; 
randy = 10.0 * randnum() - 5.0; 
randz = 10.0 * randnum(); 
while (getbutton(MOUSE2)); 
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/*} 

popattributes(); 
popviewport(); 
popmatrix(); */ 

} 

else { /* reject currently designated target */ 

ringbell(); 

*designate = TRUE; 

/* re-adjust tilt and pan values appropriately */ ; 

} 

} 

if (*greyscale != getvaluator(DIAL3)) { /* DIALS indicates color change */ 
*greyscale = !*greyscale; 

setvaluator(DIAL3,*greyscale,0,l); 
colorramp( *grey scale, F ALSE) ; 

} 



*speed = (float) (getvaluator(DlAL2) / SPEEDSENS); /* get desired speed */ 
*alt = (Coord) (getvaluator(DIAL4)); 

*pan = DTOR * (double) (-getvaluator(MOUSEX)) / PANSENS; 

*tilt = DTOR * (double)(getvaluator(MOUSEY)) / TILTSENS; 

*compassdir = (float)getvaluator(DIALO) / DIRSENS; 

/* keep *direction between 0 and 360, update valuator if changed */ 
if (*compassdir >= 360.0) { 

*compassdir -= 360.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS), (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

} 

if (*compassdir < 0.0) { 

*compassdir += 360.0; 

setvaluator(DIALO,(int)(*compassdir*DIRSENS), (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 

} 

/^convert ^direction from compass degrees to trigonometric radians */ 
*direction = (*compassdir <= 90.0) ? DTOR * (90.0 - *compassdir) : 

DTOR * (450.0 - *compassdir); 

1 

} 
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READDATA 



/* reads the raw 16 bit elevation and vegetation code data 
from the DMA data file and inserts it into the global 
gridpixel array */ 



^include *’fogm.h" 
^include *'files.h” 



readdata() 

{ 



int fd; /* file descriptor for 

short row, col, rowoffset, colofFset; 
extern short gridpixel(lOO][lOO]; 



the data file */ 

/* loop indicies */ 

/* DMA elev and veg. data 



V 



/* read the data from the data file into the gridpixel array */ 

fd = open(TERRAIN^FILE,RD); 

lseek(fd,0,0); 

for (colofFset = 0; colofFset < NUMXGRIDS * 10; colofFset += 10) { 

for (rowoffset = 0; rowoffset < NUMZGRIDS*10; rowoffset += 10) { 
for (col = 0; col < 10; -^^col) { 

for (row = 0; row < 10; 4-^row) { 

read(fd,&:gridpixel[rowofFsetT‘row][coloffset-j“Col],2); 

} 

} 

} 

} 

} 
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ROAD BOUNDS 



^include "math.h" 

^include "fogm.h" 

^define X 0 
^define Y 1 
^define Z 2 

^define NONE 0 

road bounds(ptl, pt2, pt3, road width, left_ptl, right_ptl, left pt2, 
right_pt2, first_xgrid, first_zgrid, lastj>cgrid, last^zgrid) 

float ptl[3], pt2[3], pt3[3], road width; 

float left_ptl[3], right_ptl[3), left_pt2[3], right_pt2[3]; 

int *first_xgrid, *last_xgrid, *first_zgrid, *last_zgrid; 

{ 

float delta x, deltajz, seg^dir, min_x, max_x, min z, max z; 
float left endl[3], right_endl(3], left_start2[3], right_staxt2[3], 
left_end2[3], right_end2[3]; 
int intersection_type; 

/* determine the corner points of the segment */ 
deltajt = pt2[X] - ptl[X]; 
delta_z = pt2[Z] - ptl[Z]; 
seg_dir = atan2(delta_z, delta_x); 

left endl[X] = pt2[X] -f (cos(segjiir -{- HALFPI)*road width/2.0); 
right_endl[X] = pt2[X] -{- (cos(seg_dir - HALFPI)*road_width/2.0); 
left_endl[Z] = pt2[Z] -{- (sin(seg_dir -f HALFPI)*road_width/2.0); 
right_endl[Z] = pt2[Z] + (sin(seg_dir - HALFPIj'^road width/2.0); 

if ((pt2[X] != pt3[X]) II (pt2[Z] != pt3[Z])) { 

/* we are not working with the final segment of this road, find 
the intersection of this segment with the next one */ 
delta_x = pt3[X] - pt2[X]; 
deltajz = pt3[Z] - pt2[Z]; 
seg_dir = atan2 (deltajz, delta j>c); 

left_start2[X] = pt2[X] -h (cos(seg_dir -{- HALFPI)*road_width/2.0); 
right_start2[X] = pt2[X| (cos(seg_dir - HALFPI)*road_width/2.0); 
left_start2fZl = pt2fZ] -f (sin(seg dir H- HALFPT)*road width/2.0); 
right_start2IZl = pt2!Z| — (sinfseg _dir - HALFPIj'^road width/2.0); 
left^end2lX] = ptSlXi -h (cos(seg_dir -- HALFP!)*road^width/2.0); 
right_end2[Xj = pt3[X| + (cos(seg_dir - HALFPI)^road_width/2.0); 
left _end2[Z] = pt3[Z] -{- (sin(seg_dir -h HALFPI)*road_width/2.0); 
right_end2[Z] = pt3[Z] -h (sin(seg dir - HALFPI)*road_width/2.0); 

I* find the intersection point of the left hand sides of the 
first and second road segments */ 
line_intersect2(left_ptl, left jendl, left_start2, left end2, 
left_pt2, ^intersection type); 
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if (intersection^type == NONE) { 
left_pt2[X] = left_endl[X]; 
left_pt2[Z] = left_endl[Z]; 

} 

/* 6nd the intersection point of the right hand sides of the 
first and second road segments * j 
line intersect2(right_ptl, right endl, right staxt2, right end2, 
right_pt2, &:intersectionJtype); 
if (intersection_type == NONE) { 
right_pt2[X] = right jendljX]; 
right_pt2[Z] = right_endl[Z]; 

} 

} 

else { 

/* this is the final segment of this road */ 
left_pt2[X] = left_endl[X]; 
left_pt2[Z] = left_endl(Z]; 
right_pt2[X] = right_endl[X]; 
right_pt2[Z) = right_endl[Z]; 

} 

/* determine the min and max x and z values */ 

min_x = left_ptl[X]; 

max X = left ptljX]; 

min z = left_ptl[Z]; 

max_z = left^ptl[Z|; 

if (right_ptl[X] < min_x) min_x = right_ptl(X]; 
if (right_ptl[X] > max_x) max_x = right_ptl[X]; 
if (right__ptl[Z] < min^z) min_z = right j>tl(Z]; 
if (right^ptl[Z] > max_z) max_z = right_ptl[Z]; 
if (left^pt2[X] < min_x) min__x = left_pt2[X]; 
if (left_pt2[X] > max_x) max_x = left_pt2[X]; 
if (left_pt2[Z] < min_z) min_z = left_pt2[Zj; 
if (left_pt2[zj > max_z) max_z = left_pt2[Z]; 
if (right^pt2[X] < min^x) min_x = right_pt2[X]; 
if (right_^pt2[X] > max_x) max_x = right_pt2[X]; 
if (right_pt2[Z] < min_z) min_z = right_pt2[Z]; 
if (right_pt2(Z] > max_z) max_z = right_pt2[Z]; 

*first_xgrid = (int)(min_x/FT_100M); 

*first_^zgrid = (int)(min^z/FT_100M); 

*last_xgrid = (int)(max_^x/FT_100M); 

"'last _2 grid = (int )(max^ 2 / FT_iOOM); 
if (* first xgrid < 0) ^ first _xgrid = 0; 
if (*first_zgrid < 0) *first_^zgrid = 0; 
if (*last_xgrid > 98) *last_xgrid = 98; 
if (*last zgrid > 98) *last zgrid = 98; 
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SORT ARRAY 



sort array (array, num entries, decending, test_index) 
float array [lO] [3]; 

int num_entries, decending, test_jndex; 

{ 

int ij; 

float temp[3]; 

for (i = 0; i < num_entries; -h-hi) { 

for (j = i + 1; j <= num_entries; ++j) { 

if (((decending) && (array [j][test_index] > array[i][test_index])) || 
((Idecending) ( array [j][ test _index] < array[i][test_index]))) { 

temp[0] = array[i][0]; 
temp[l] = array[i][l]; 
temp[2] = array[ij[2]; 
array(i][0] = array[j][0); 
array[ij[l] = array[j][lj; 
array[i][2] = array[j][2]; 
array [j][0] = tempjO]; 
array[j|[l] = temp[l]; 
array[j][2i = temp(2]; 

} 

} 

} 

} 
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UP LOOK POS 



/* compute the camera’s lookat position */ 

^include ’’fogm.h" /* fogm constants */ 

^include "math.h" /* math routine definitions */ 

#include ”gl.h” /* graphics definitions */ 

update look posit(direction, pan, tilt, vx, vy, vz, 
tgtx, tgty, tgtz, designate, px, py, pz) 

double direction, pan, tilt; 

Coord vx, vy, vz, tgtx, tgty, tgtz, *px, *py, *pz; 
int designate; 

{ 

extern int framecnt; 
double lookdir; 

if (designate) { /* missile is not locked on to a target */ 

/* compute direction camera is looking * / 
lookdir = direction pan; 

/* compute a coordinate along camera’s line of sight */ 
*px = vx + cos(lookdir) * MAXLOOKDIST; 

*pz = vz - sin(lookdir) * MAXLOOKDIST; 

if (framecnt < 15) { 

*Py = * vy * (14 - framecnt) / 14.0; 

framecnt-h-h; 

} 

else { 

*py = vy + MAXLOOKDIST * tan(tilt); 

} 

} 

else { 

*px = tgtx; 

*py = tgty; 

*pz = tgtz; 

} 



1 
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UP MSL POSIT 



/* Compute new missile position */ 



^jfinclude "gl.h" / 

^include "device. h” 
^include "fogm.h" 
^include "math.h" 
^include <sys/types.h> 
^include <sys/times.h> 



* graphics definitions */ 

/* graphics device definitions */ 

/* fogm constants */ 

/* math function declarations */ 

/* contains the time sturcture tms 
/* for time calls */ 
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update missile posit (direction, compassdir, speed, designate, 
tgtx, tgty, tgtz, vx, vy, vz, flying) 



double *direction; 
float *compassdir; 
float speed; 
int designate; 

Coord tgtx, tgty, tgtz; 
int *flying; 

Coord *vx, *vy, *vz; 



static long seconds; 

static long lastsec = -999; /* -999 is flag to indicate no value */ 

struct tms timestruct; 

float deltadist, gndlevel, gnd_level(), compass(), ht_above_tank; 
long float deltax, deltaz, dist to tank; 

seconds = times(&timestruct); 

/* compute distance missile must move ahead to maintain speed */ 
if (lastsec == -999) 
deltadist = 0.0; 

else 

deltadist = (speed/FPS_TO_KTS)* (seconds - lastsec); 
lastsec = seconds; /* save for next pass */ 

if (designate) { /* missile under operator contol, not locked on tgt */ 

*vx -h= deltadist * cos(*direction); 

*vz -= deltadist * sin(*direction); 

/* keep missile at least 50 ft above ground level ^ 

gndlevel = gnd_level(*vx, ^vz); 

if (*vy < (gndlevel 4- 50.0)) *vy = gndlevel + 50.0; 

} 

else { 



deltax = *vx - tgtx; 
deltaz = *vz - tgtz; 
dist^^to^tank = hypot (deltax, deltaz); 
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if (deltadist > (float)dist to tank) { /* hit on target */ 

deltadist = (float)dist_to_tank - 5.0; 

*flying = FALSE; 

lastsec = -999; /* no value flag for next launch */ 

} 



*direction = (double)atan2((float)deltaz, (float)-deltax); 
if (*direction < 0.0) *direction += TWOPI; 

*compassdir = compass(*direction); 

setvaluator(DIALO,(int)(*compassdir*DIRSENS), (int)(-360*DIRSENS), 
(int)(720*DIRSENS)); 



*vx += (deltadist * cos(*direction)); 

*vz -= (deltadist * sin(*direction)); 

ht above tank = (float)*vy - gnd level(tgtx,tgtz); 

*vy -= (Coord) ((ht_above_tank * deltadist) / (float)dist_to_tank); 

} 

} 
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VIEW BOUNDS 



^include "fogm.h" 

^jjtinclude '^gl.h" 

^include ”math.h” 

view_bounds(vx, vy, vz, px, py, pz, tilt, fovy, 
firstxgrid, firstzgrid, lastxgrid, lastzgrid) 

Coord vx,vy,vz; 
double tilt; 
int fovy; 

short *firstxgrid, *firstzgrid, *lastxgrid, *lastzgrid; 

float ix, iz; /* the intersection points * j 
float lookdir; 

float deltax, deltay, deltaz, delta_^alt, fx, fy, fz; 

float half^fovy; 

float lower edge angle; 

/* compute the direction the camera is looking */ 
lookdir = atan2( (float) (vz - pz), (float)(-(vx-px))); 
if (lookdir < 0.0) lookdir 4-= TWOPI; 

if (vy > py) { 

/* tilt angle is negative */ 
deltax = px - vx; 
deltay = py - vy; 
deltaz = pz - vz; 

delta alt = pow((float)MIN, ALTSCALE) - vy; 

} 

else { 

/* tilt angle is positive, use the lower fustrum edge instead 
of the line of sight to compute the view bounds * j 
/* compute a coordinate along the lower fustrum edge */ 
half_fovy = ((float)fovy/20.0*DTOR); 
lower edge angle = tilt - half fovy; 
fx = vx + cos(lookdir)*MAXLOOKDIST; 
fz = vz - sin(lookdir)*MAXLOOKDIST; 
fy = vy + tan(lower_edge_angle)*MAXLOOKDIST; 
deltax = fx - vx; 
deltay = fy - vy; 
deltaz = fz - vz; 

delta_alt = pow((floac)MIN, ALTSCALE) - vy; 

} 

ix = vx + ((deltax/deltay)*delta alt); 
iz = vz -h ((deltaz/deltay)*delta^alt); 



/* compute which grid objects should be sent through the geometry 
pipeline * / 
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if (deltay > 0.0) { 

/* the fustrum is looking totally skyward, don’t bother doing 
any terrain */ 

*firstxgrid = 0; 

*firstzgrid = 0; 

*lastxgrid = 0; 

^lastzgrid = 0; 

} 

else { 

/* display 20 grid squares on all sides of the intersection point */ 
*firstxgrid = (int)(ix/FT_100M) - 20; 

*lastxgrid = (int)(ix/FT_100M) -f- 20; 

*firstzgrid = (int) (-iz/FT_100M) - 20; 

*lastzgrid = (int)(-iz/FT_100M) -f- 20; 

/* insure that objects drawn include the current missile position */ 
if ((int)(vx/FT_100M) < *firstxgrid) 

*firstxgrid = (int)(vx/FT__100M); 
if ((int)(vx/FT_100M) > ^^lastxgrid) 

*lastxgrid = (int)(vx/FT_100M); 
if ((int)(-vz/FT_100M) < *firstzgrid) 

*firstzgrid = (int) (-vz/FT_100M); 
if ((int)(-vz/FT^100M) > *lastzgrid) 

*lastzgrid = (int) (-vz/FT_100M); 
if (*firstzgrid < 0) ^firstzgrid = 0; 
if (*firstxgrid < 0) *firstxgrid = 0; 
if (*lastzgrid > 98) *lastzgrid = 98; 
if (*lastxgrid > 98) *lastxgrid = 98; 

} 

} 
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